vmWare Workstation 8 - Netzwerkverbindung wird getrennt

[LKaderavek]

Hallo,

ich habe auf einem Windows 7 Professional x64 eine Workstation 8 in Verwendung und muss in dieser eine Windows XP Maschine betreiben.

Leider scheint die vm die Netzwerk-Verbindung zu verlieren.

In der vm wird eine Datenbank-Anwendung, die nicht mehr mit Windows 7 gestartet werden kann betrieben.

Leider ist das sehr instabil und es kommt immer wieder zu Verbindungsfehlern.

Ich habe bereits alle Green-IT Komponenten deaktiviert.

Die Netzwerk-Konfiguration ist als NAT definiert.
Am vHost ist DHCP aktiviert und die DNS-Auflösung im Host-Netzwerk klappt ohne Probleme.

Am Host wurden die Energieoptionen angepasst, die NIC darf nicht mehr deaktiviert werden um Strom zu sparen.
Am vHost habe ich die Energieoptionen auf Immer-An gesetzt, sodass keine Stromspar-Funktion genutzt wird.

Bitte um Info, ob jemand schon so ein Phänomen beobachtet und gelöst hat.

Danke

Ciao

Lukas

[Dayworker]

Ist die Host-Nic ständig mit einem Router oder Switch verbunden?
Wieviel vRAM hat deine VM spendiert bekommen?
Über wieviel RAM gebietet der Host?

VMware auf die Ausnahmelisten von Virenscanner, Firewall und sonstigen Unsicherheits-Suiten gesetzt?

[LKaderavek]

Hallo,

also die NIC ist ständig per Gigabit verbunden.

Der Host hat 4GB, die VM 1GB.

Als Virenschutz läuft am Host Security Essentials.

Am Host ist die Verbindung ständig aufrecht.
Wir haben das bereits mit Ping und einer anderen DB getestet.

[Dayworker]

Als was (öffentliches Netzwerk, Domäne etc) ist das VMware-Interface eingeloggt?
Firewall überprüft oder testweise mal deaktiviert?

[LKaderavek]

Hallo,

also die VM ist mit dem DC verbunden.
Der User in der vm ist ein AD-Account.

Firewall am vHost ist deaktiviert.
Am Host laufen wie gesagt die Security Essentials.
Ich habe jetzt den Echtzeitschutz und die Firewall am Host einmal abgedreht...

Wenn die VM jetzt ca. 2 Minuten im Leerlauf habe ich aber trotzdem "Windows - Datenverlust beim Schreiben"

[Dayworker]

Jetzt ist die Fehlermeldung aber eine andere, denn vorher hattest du nur über Verbindungsprobleme geklagt.
Mit der neueren Fehlermeldung läßt sich aber M$ Security Essentials als Fehlerquelle bestimmen und leider bietet M$ keine Möglichkeit, Ausnahmenregelungen zu erstellen. Für den Einsatz auf einem virtualisierenden Host ist das ein K.o-Kriterium.

Oder wo genau taucht die Meldung "Windows - Datenverlust beim Schreiben" auf?

[LKaderavek]

Hallo,
die Meldung erhalte ich in der VM...am Host kann ich die Anwendung ohne Verlust betreiben, leider ist die Anwendung aber nur begrenzt nutzbar, da die Schriftdatenbank von Windows 7 mit den Belegen nichts anfängt und alles zusammenschiebt.

Deshalb haben wir eine XP-VM eingerichtet und in der eben jetzt andere Probleme...

PS: In Security Essentials kann man sehrwohl Ausnahmen definieren...entweder auf File oder Verzeichnisebene...die Security Essentials stören aber definitiv nicht.

[UrsDerBär]

Habe das auch ab und wann auf einer VM gehabt. Ursache war hier eine serbelnde Festplatte. In Windows-Normalgebrauch hatte das erstmal keinen Einfluss aber VmWare Workstation scheint da etwas anspruchsvoller mit Festplattenzugriffen zu sein. Auf alle Fälle kackte nach ein paar Wochen die HD weg.

Eine weitere Ursache könnte sein, wenn die VM auf einem Netzwerkshare liegt. Da gibts das ab und wann auch wenn die Leitung nicht so prickelnd ist.

Solange die VM nicht abserbelt und die Meldung sich nicht nach kürzester Zeit wiederholt ist es eigentlich nicht so tragisch. Die Daten werden dann irgendwann trotzdem korrekt hingeschrieben *Schulterzuck*

Natürlich kein Dauerzustand und sollte behoben werden...

[LKaderavek]

Also, so einfach ist es mit den Daten nicht...

Dieses Phänomen zerstört die Datenbank und schreibt Zeilen mehrfach...das haben wir leider am Produktiv-System schon feststellen müssen.

An der Festplatte liegt es glaube ich nicht...könnte aber ein Anhaltspunkt sein...

Soll ich den WriteCache einmal deaktivieren?

[Dayworker]

Der Grund weshalb die WS das eher mitbekommt ist, daß die VMDKs immer CRC32 überprüft werden. Ich hatte das feststellen müssen, als mein Raid einen Lesefehler meldete und daraufhin VMware eine CRC32-Fehlermeldung ausgab. Scheinbar lag die VMDK genau auf dem Sektor mit dem Lesefehler. VMware bietet dann übrigens immer noch das erneute Auslesen an, was im Normalfall meist noch klappt und fährt dann die VM runter. In meinem Fall hat VMware die VM sicherheitshalber komplett hart abgeschaltet.


Vermutlich wird eine Deaktivierung des Write-Cache daran keine Auswirkungen haben, zumal du diesen zumindest unter einem Desktop-Windows meines Wissens auch nicht mit den Bordmitteln beeinflussen kannst. Wenn bei dir natürlich ein Raid egal ob als Fake oder HW werkelt, sieht die Sache schon etwas anders aus. Davon hattest du dann aber bisher noch nichts verlauten lassen...

[UrsDerBär]

Oha, ne also ich hatte bis dato zum Glück noch nie Probleme mit erneut wiedergeschriebenen Blöcken. Allerdings bin ich auf den produktiven Systemen (weils halt nicht anders geht, Dongle-Geschichte) immer noch bei 6.5.x stehen geblieben...


aber eben, so Sicherheitssoftware schmeckt der Workstation aber selten sonderlich gut. Die VM-Ordner sollte man zumindest ausklammern bzw. die Endungen davon...