Windows - Datenverlust beim Schreiben

[BimboBanani]

hi @all!

Bin mittlerweile mega-frustriert von VMWare!

Habe die Programmierumgebung (Delphi) in der VMWaer-Session laufen. Ständig kommt beim Kompilieren die o.a. Meldung. Fazit: Ich kann die Session herunterfahren UND den Host ebenfalls, weil nämlich dort alle möglichen Dateien gesperrt sind. Wenn ich Pech habe, passiert mir das 2-3x hintereinander. Zeitaufwand jedesmal etwa 15 Minuten.

Das Problem war auf meinem vorigen (langsameren) Windows7-Host ncht so extrem, aber vorhanden.

Hintergrund:
VMWare Workstation, sowohl 7 als auch 8
VMWare-Client: Windows XP Prof. SP3
Host: Windows 7
Network Adapter: bridged

Thema 1:
Programm (Delphi) im Client (hier also Durchführung komplieren), Quellcode und zu kompilierende EXE, DCUs usw. auf Laufwerk D:, welches eine Partition vom Host ist.
Mapping des Laufwerkes D: ganz normal über Freigabe und Netzlaufwerk verbinden und nicht über die Shared Folders, weil es mit diesen extrem langsam geht (Kompilierung statt 2-3 Sec. ca. 5-6 Min!)

Thema 2:
Bei einem Kollegen (und auch bei mir) tritt ein dazu passendes Problem auf, wenn er viele Dateien aus der Client-Session auf irgendein Netzlaufwerk kopiert: Nach einigen Dateien ist die Netzverbindung weg und zwar so nachhaltig, dass nur ein Reboot hilft.

Bei der Netzwerkkarte beim host alles was mit offload zu tun hat disabled:
ARP Offload Aktiviert > Deaktiviert
IPv4 Prüfsummenabladung Rx & Tx aktiviert > Deaktiviert
NS Offload Aktiviert ' Deaktiviert
TCP Prüfsummenabladung (IPv4) Rx & Tx aktiviert > Deaktiviert
TCP Prüfsummenabladung (IPv6) Rx & Tx aktiviert > Deaktiviert
UDP Prüfsummenabladung (IPv4) Rx & Tx aktiviert > Deaktiviert
UDP Prüfsummenabladung (IPv4) Rx & Tx aktiviert > Deaktiviert

Schließlich hab ich in der Session (also beim XP) die Netzwerkkarte auf 100MBit/Halbduplex gesetzt, dass sich die nicht verschluckt. Kommt mir zwar komisch vor, bringt aber milde Besserung, denn bei automatischer Zuordnung geht schon gar nichts.

Alle möglichen Foren etc. durchsucht und nirgends was gefunden. Das scheinen doch essentielle Probleme zu sein, wieso hört man da nichts davon?

Neben der Bitte um Unterstützung: Habt Ihr eine Idee, wohin ich mich noch wenden kann?

Herzliche Grüße
Martin

[Dayworker]

Bekannt von WS7/WS8 unter W7/W2k8/W2k8-R2 ist, daß sie bei Vergabe von mehr als 40% des Host-RAMs an VMs instabil werden. Dies zeigt sich unter anderem am Bridged-Interface, daß dann scheinbar komplett wegbricht.
Daher lautet die Frage, wie sind Host und Gast arbeitsspeichermäßig ausgestattet?

Mußt du unbedingt die SharedFolders nutzen oder kannst du nicht einfach eine normale Netzwerkfreigabe einrichten?
Bei einigen WS-Versionen waren die SharedFolders chronisch unzuverlässig...


Da im Kauf der WS auch Support enthalten war, sollten dein nächsten Anlaufpunkte das offizielle VMware-Forum und dann der Support sein.

[BimboBanani]

Hallo Dayworker!

Habe 4GB RAM (von denen er ca. 3,3 verwenden kann > 32bit) und die VMWare-Session auf 512 MB gesetzt. Ist also noch weit unter den 40%.

Das eigenartige: Bei einem Kollegen, der allerdings nicht mit Workstation, sondern Player probiert hat (und auch nur die Standard-RAM-Vergabe hat), tritt beim Kopieren das selbe Propblem auf, also dass er sich nach einer Anzahl kopierter Dateien vertschüsst.

Netzwerk hab ich eh nicht auf SharedFolders, sondern normal verbunden.

Werde aber Deinen Tip beherzigen und RAM auf 256 runterschrauben. Hatte ich nur für Delphi erhöht, da ich ja auf dem Host eh genug habe.
Auch das VMWare-Forum werde ich besuchen.

Mit einer Rückmeldung wird es etwas dauern, da manchmal das Problem tagelang nicht auftritt und dann gleich ein paarmal hintereinander.

Gruß
Martin

[Dayworker]

Also mit 512MB ist XP doch gut ausgestattet, darunter solltest du speziell mit installiertem SP3 nicht gehen, die Geschwindigkeit sinkt ins Bodenlose. Aufgrund der vermehrten Swap-Aktivitäten des Gastes wird die Host-Festplatte unnötig beschäftigt...

Ich würde dir daher eher eine Optimierung von "config.ini" und "*.vmx" empfehlen. Damit VMware möglichst wenig den normalen Rechnerablauf stört, sind einige Parameter weniger optimal voreingestellt, die die Geschwindigkeitsunterschiede nicht nur meß- sondern auch fühlbar machen.

Delphi ist bisweilen sehr wählerisch in RAM-Bestückung und -Zugriff. Delphi springt beim Kompilieren besonders gerne im kompletten Adressraum umher und etwaige RAM-Schwachstellen zeigen sich dort besonders schnell. Solche Schwachstellen sind neben realen Defekten manchmal auch nicht beabsichtigte Übertaktungen.
Um den RAM zu testen, empfehle ich immer "Prime95" oder das darauf aufbauende "Orthos Multiprime". Damit erhältst du verläßliche Angaben, die auch gegenüber einem Händler bestand halten. Bei "Memtest" liessen sich solche reproduzierbaren Ergebnisse nur erreichen, wenn man alle Caches (so sie denn abschaltbar sind) deaktiviert und jeden Riegel einzeln testet.

[Nukite2007]

Hallo martin,

Hatte ein ähnliches Problem und dies lösen können.
Schau mal hier http://vmware-forum.de/viewtopic.php?p=121794#121794

Viel Glück
Peter

[BimboBanani]

Hallo Peter!

Habe die Einstellungen durchgeführt und bin seeehr neugierig! Werde Feedback posten, wird aber etwas dauern, möchte warten bis ich sicher bin, dass es nicht mehr kommt.

Dankeschön!

Viele Grüße
Martin

[Nukite2007]

Hi,

ja würd mich auch interessieren was dabei rausgekommen ist. Also poste das Ergebnis.

Servus
Peter

[BimboBanani]

Hi Peter,

eine Frage hab ich noch:
Auf welchen Wert hast Du 'MaxMpxCt' gesetzt (Range 50-65535)?

Gruß
Martin

[Dayworker]

Bist du dir sicher, daß das Netzwerk der einzig limitierende Faktor ist?
Speziell eine Sparse-Disk (mitwachsende vDisk) oder ein aktiver Snapshot können jede Schreibperformance im Keim ersticken und gerade der Schreibzugriff ist durch die vollständig virtualisierte VM-HW immer der Knackpunkt. Je nach Host- und Gastauslastung sind hier Schreibwerte zwischen 1/4 bis 1/3 der nominalen Hostschreibleistung als normal zu nennen.
Selbst eine SSD kann da nicht mehr rausholen, erreicht aber aufgrund der höheren Schreibleistung und vor allem der wesentlich höheren IO-Anzahl eine viel bessere Performance.

[Nukite2007]

Ich habe bei meinem Testsystem damals den höchsten Wert eingegeben (65535)

VG
Peter

[BimboBanani]

Hallo, hier bin ich wieder - leider

bis dato passiert es doch immer wieder, bin mir nicht sicher, ob es seltener ist. Wenn das Werkel mal läuft, dann funktioniert er meistens 2-3 Tage. Beim erstenmal kompilieren nach Neustart werden die meisten dcu's neu gebildet und da krachts dann.
Also das selbe Phänomen wie beim Kopieren mehrer Dateien. So, als ob es ein Problem beim schnellen Zugriff bzw. Schreiben auf den Dateiindex der virtuellen VMWare-Festplatte gäbe.

Werde jetzt den Wert von 'MaxMpxCt' in der Registry mal auf FFFF raufschrauben, dann berichte ich wieder.

Schönes Wochenende!
Martin

[continuum]

Musst du einen Windows 7 host verwenden ?

Mittlerweile halte ich von Windows7 als Host soviel wie von Jack-the-Ripper als Babysitter

[Dayworker]

...und Windows8 wird da sicher noch nerviger werden.

[stefan.becker]

Musst du einen Windows 7 host verwenden ?

Mittlerweile halte ich von Windows7 als Host soviel wie von Jack-the-Ripper als Babysitter

He, mach nir nicht den Onkel Jack schlecht

[e-e-e]

Jack hat doch "nur" Huren gemeuchelt, wieso also nicht auf Babies aufpassen lassen?javascript:emoticon(':D')