VM-Ware Workstation suspend dauert lange

[tmarkl]

Hallo,

ich habe ein VM-Workstation image mit 260 GB Inhalt (vmdk-file).
Wenn ich die Virtuelle Maschine eccehp5 starte, dann wird auf dem C-Laufwerk ein Unterverzeichnis "virtual machines" angelegt mit einem Unterverzeichnisname "eccehp5 on pc" so wie die Virtuelle Maschine eben heißt.
Das Unterverzeichnis enthält dann ein weiteres Unterverzeichnis "Cache" sowie diverse VM-Ware-Dateien, die nicht das vdmk-file sind, sondern etwas mit dem laufenden Betrieb des Virtuellen Systems zu tun haben z. B. eine .vmem-Datei.

=> Das Virtuelle System läuft insgesamt bei 8 GB Ram sehr flüssig, aber beim Suspend dauert es z. B. 15-30 Minuten bis die enorme Festplattenaktivität aufhört.
Das möchte ich verkürzen.

Dazu habe ich einige Fragen:
1. Die vmem-Datei ist eigentlich eine Datei, die lt. VMware nur für den laufenden Betrieb den Inhalt des RAMs der virtuellen Maschine hat.
Warum ist diese auch nach laufenden Betrieb auf der C-Platte im Verzeichnis Virtual Machines vorhanden (Sie ist ca. 4 GB groß). Im vmware-log habe ich dazu folgendes gefunden: Anscheinend wird das vmem-File beim Suspend der Virtuellen Maschine angelegt:

MainMem: Keep paging file '.\eccehp5_local_on_pc-02498991.vmem' as memory image.

Wird da praktisch der Inhalt des VM-Rams auf das File geschrieben und ist es das, was so lange dauert und solche Festplattenaktivität beim SUSPEND verursacht?

Könnte das mit dem Befehl "config.ini: mainmem.useNamedFile = "FALSE" gelöst werden bzw. was wären die Auswirkungen der o. g. Einstellungen auf die Geschwindigkeit der Virtuellen Maschine im laufenden Betrieb zum einen und beim Suspend zum anderen?

Hinweis: Beim Starten der Virtuellen Maschine zeigt das logfile folgenden Fehler: Cannot open file "C:\Users\thma1\AppData\Roaming\VMware\config.ini"

Vielen Dank im voraus für eure Antworten.

[Dayworker]

Wenn du das Anlegen des VM-Unterverzeichnisses verhindern willst, erstelle manuell einen Unterordner "Virtual Machines" bevorzugt im Hauptpfad und lege diesen als neuen Datastore fest. Dann wird auch eine "config.ini" in deinem VMware-Benutzerordner erstellt. Alle vorhandenen VMs kannst du dorthin verschieben und neue VMs werden nur noch da gespeichert. Im empfehle immer einen neuen Ordner im Hauptpfad zu nehmen, da bei VMware neue VMs standardmäßig immer den OS-Namen bekommen (läßt sich bei jeder VM immer ändern) und somit die Ordnernamen sehr lang werden können. Wenn man dann seine VMs noch in weitere Ordner thematisch sortiert, erreicht man unter Umständen von Windows nicht mehr unterstützte Verzeichnistiefen bzw Pfadlängen.

Für die IO-Leistung einer VM (SSDs mal aussen vorgelassen) ist es auch nicht verkehrt, den VM-Ordner auf einen zweiten Datenträger, also keine weitere Partition auf dem das Host-OS lagernden Datenträger, auszulagern. Aber die Trennung von OS und Benutzerdaten sollte inzwischen selbstverständlich sein.


Die mem-Datei bildet den vRAM des Gasts auf den Datenträger ab. Gleichzeitig wird unbenötigter vRAM aber sowieso an den virtuellen Arbeitsspeicher des Hosts freigegeben. Falls du eine VM mit viel vRAM konfiguriert hast, wird dieser Speicher beim Beenden und Suspenden erst noch auf die Platte weggeschrieben. Mit deiner genannten Einstellung kannst du das Verhalten entweder global in der "config.ini" oder einzeln in jeder VMX-Datei beeinflussen.

[tmarkl]

Hallo Dayworker,
vielen Dank für Deine Antwort.
Wie kann ich den Suspend beschleunigen? Geht das mit dem "config.ini: mainmem.useNamedFile = "FALSE" ?
Wie mein log-file zeigt, wird ja erst beim suspend die vmem-Datei geschrieben. Aber soweit ich weiß wird doch die vmem-Datei für den laufenden Betrieb immer erzeugt. Wahrscheinlich wird sie aber im RAM meines Host-Rechners gehalten und dann erst beim Suspend geschrieben, oder?
Warum dauert das Schreiben der vmem-Datei so lange? Wenn ich suspend geht das schnell, aber die Festplatte kommt erst nach ca. 15 min zur Ruhe.

[Dayworker]

Prinzipiell gilt in der Virtualisierungswelt die Maxime: Nur soviel (RAM, DISK, CPU) wie nötig und nicht wie möglich.
Wenn du einer VM je nach genauer WS-Version mehr als 768-1536MB RAM gönnst, wird der Großteil davon von VMware als "auslagerungsfähig" gekennzeichnet und dem kommt das Host-OS umgehend nach. Wenn du im Win-Taskmanager dir den RAM-Verbrauch deiner VM mit 8GB vRAM anschaust, wirst du sehen, daß von 8GB gerade mal noch 500MB im Host-RAM gehalten werden und der Rest im virtuellen Arbeitsspeicher des Host lagert. Mit der vmem-Datei verschärft sich die Lage sogar noch weiter. Wenn du die VM anhältst, fragt VMware den im virtuellen Arbeitsspeicher liegenden vRAM der VM an und das Host-OS schiebt diesen wieder Stück für Stück in den pRAM, welchen die WS dann direkt wieder auf die Platte wegschreibt. Im Prinzip schreibst du dadurch volle 16GB weg und wenn du nicht gerade eine SSD hast, wächst dir zwischenzeitlich ein Bart...

[tmarkl]

Hallo,

bei mir ist ja gerade die Default-Einstellung, daß ich config.ini: mainmem.useNamedFile = "TRUE“ habe. Jetzt habe ich gelesen, daß wenn man nur EINE virtuelle Maschine betreibt (also nicht mehrere gleichzeitig), die Einstellung mainmem.useNamedFile = "FALSE“ die bessere ist. Momentan (mainmem.useNamedFile = "TRUE“) schreibt die virtuelle Maschine gem. Logfile die .vmem-Datei nur, wenn die Maschine suspended wird.
Ich habe von den 8GB im Rechner der virtuellen Maschine 4 GB RAM zugebiligt, die beim suspend auch exakt in der gleichen Größe auf die .vmem-Datei weggeschrieben werden.

Meine Frage ist: Welche Einstellung (RAM der VM; mainmem.useNamedFile…) sind für meine virtuelle Maschine am besten? Die Virtuelle Maschine soll weiterhin flüssig laufen, aber wenn möglich sollte der Suspend einfach schneller gehen.

[Dayworker]

In der virtualisierten Welt geht man mit RAM, CPU und vDISK so klein wie möglich ran. Es ist daher nicht verkehrt, eine Singlecore-VM mit 512MB-1024MB RAM und 10GB Platte zu erstellen.
In der VMware-Welt bekommt eine VM nur dann Rechenzeit zugeteilt, wenn die für die VM konfigurierte Kern/CPU-Anzahl auf dem Host auch frei ist (dürfte bei einer Singlecore-VM mindestens 75% häufiger als bei Quadcore-VM der Fall sein), sie laut RoundRobin-Mechanismus an der Reihe ist oder wenn sie aufgrund freier Kerne mehrfach nicht zum Zuge kam und der dafür eingestrichene Bonus für die nächste RR-Runde inzwischen hoch genug ist und die VM für eine einzige Ausführungseinheit ausgeführt wird. Sowas macht sich dann als Ruckeln bzw hakelige Bedienung in der VM bemerkbar.

Der Grund für die kleine vDISK ist dem Hintergrund geschuldet, daß du eine VMDK jederzeit über die WS/Player-Anwendung äusserlich vergrössern und nachher innerlich über die Partitionierungswerkzeuge des Gastes aufblasen kannst, aber der direkte Rückweg versperrt ist. Zum Verkleinern ist entweder ein je nach vDISK-Grösse sehr langwieriger Converter-Durchlauf oder viel Handarbeit nötig. Eine kleine Gast-HDD hat auch den Vorteil, daß man eher an eine immer sinnvolle Trennung von OS mit Anwendungen und Daten denkt.
Damit die VM allgemein schneller wird, was meist eine bessere IO-Leistung erfordert, solltest du Host- und Gast-OS einfach auf verschiedene Platte (keine Partitionen auf derselben Platte) haben oder eine SSD einsetzen.

Wenn du nur eine VM dauerhaft am Laufen hast, könnte man wirklich über den von dir geschriebenen Parameter nachdenken. Dir sollte aber bewußt sein, daß sich dann deine lokale Win-Auslagerungsdatei auch um diesen Wert vergrössert.

[tmarkl]

Die Virtuelle Maschine läuft flüssig, doch beim Suspend wird ja die .vmem-Datei geschrieben und das dauert Zeit bzw. löst die enorme Festplattenaktivität aus.
Das will ich ja reduzieren.
Daher habe ich auch schon den Rat bekommen, die virtuelle Maschine von der C-Platte auf eine SSD zu nehmen. Allerdings hieß es, daß ich dann natürlich auch das Arbeitsverzeichnis der Virtuellen Maschine (wo u. a. die vmem-Datei beim Suspend) auch auf die SSD bringen müßte, denn sonst würde es nichts bringen. Wie schaffe ich es, daß die VM-ware ihre ganzen Dateien auf nicht mehr auf die C-Platte schreibt, sondern auf die SSD?

[Dayworker]

Unter Windows stellt sich meines Wissens die Frage nach dem Speicherort der vmem-Datei doch überhaupt nicht. Verschiebe einfach den gesamten VM-Ordner auf die SSD und starte ide VM von dort, dann liegt die vmem-Datei mit auf der SSD.

[tmarkl]

Ich probiere es jetzt erst mal mit einer externen Festplatte aus und starte die virtuelle Maschine mit Doppelklick auf die vmdk-Datei von dort aus. Mal sehen, ob dann auf der externen HDD ein Arbeitsverzeichnis für die virtuelle Maschine angelegt wird.

[Dayworker]

Was bitte soll dir ein Doppelklick auf die VMDK-Datei sprich die vDISK bringen?
Ich würds ja eher mit der VMX-Datei probieren, falls die Endung VMX bei der WS/Player-Inst damit verknüpft wurde.

[continuum]

15 - 30 Minuten für suspend sind bei WS 9 normal - wenn es schneller gehen soll nimm eine ältere Version

[tmarkl]

Ja, das habe ich gehört. Aufgrund der Größe meiner Virtuellen Maschine ist das so. Kann ich das mit der SSD deutlich beschleunigen, wenn ich die gesamte virtuelle Maschien (Arbeitsverzeichnis und Daten) auf die SSD packe?

[UrsDerBär]

Ja, das habe ich gehört. Aufgrund der Größe meiner Virtuellen Maschine ist das so. Kann ich das mit der SSD deutlich beschleunigen, wenn ich die gesamte virtuelle Maschien (Arbeitsverzeichnis und Daten) auf die SSD packe?

Ist eine SSD schneller als eine SATA-Magnet-Platte? Falls Du diese Frage beantworten kannst, dann weisst auch was schneller ist wenn nicht die CPU oder Ram-Auslastung das Problem ist.

Unter Windows stellt sich meines Wissens die Frage nach dem Speicherort der vmem-Datei doch überhaupt nicht. Verschiebe einfach den gesamten VM-Ordner auf die SSD und starte ide VM von dort, dann liegt die vmem-Datei mit auf der SSD.

[tmarkl]

Eine SSD ist je nach 4xschneller als SATA, aber auch nur, wenn die Daten, die geschrieben werden, auch auf der SSD liegen. Bislang schreibt meine VMWare Workstation die Arbeitsdaten auf die C-Platte und nicht auf die externe HDD bzw. SSD. Oder sehe ich das falsch.

[UrsDerBär]

Dein Problem ist die vmem oder? Dayworker hat dir geraten die VM auf die SSD zu verschieben, damit Deine vmem ebenfals auf der SSD liegt. Damit ist die Frage doch beantwortet oder? Falls nein, ja das dürfte deutlich schneller sein. Soviel schneller wie Deine SSD eben IOPS liefert.

[tmarkl]

Ja, damit ist das klar. Vielleicht habe ich später noch eine Frage zum Verschieben, aber die Frage ist gelöst. Ich bedanke mich für die Infos.

[Dayworker]

Welche Frage hast du denn zum Verschieben?
Ich vermute mal, daß dir entweder beim Host-Start mitgeteilt, daß die VM fehlt oder erst beim Start der WS. Das Problem löst du aber ganz locker, indem du die verschobene VM aus dem WS-Inventory nimmst und dann am neuen Ort wieder ins WS-Inventory aufnimmst. Alternativ nimmst du die verschobene VM nur aus dem Inventory und nach einem Doppelklick auf die VMX-Datei am neuen Ablageort wird diese dem Inventory wieder hinzugefügt.

[tmarkl]

Du hast recht. Ich wüßte jetzt nicht, wie das Verschieben geht. Ich weiß auch nicht, was ein WS-Inventory ist und wie man das mit dem rausnehmen und reinnehmen macht. Ich kenne mich halt mit VMs nur sehr oberflächlich aus.

[Dayworker]

Schau dir mal deine WS-Anwendung an. Auf der linken Seite werden meiner Erinnerung nach alle VMs aufgeführt und das ist das Inventory bzw Inventar. Wenn du da einen Rechtsklick auf eine nichtlaufende VM machst, stehen dir mehrere Punkte zu Auswahl. Entweder wird dir direkt der Menupunkt "Remove from Inventory" angeboten oder nur "Delete", der dann die Auswahl bringen sollte, ob die VM auch physikalisch von der Platte getilgt werden soll. Achtung, falls du da den Haken reinmachst und bestättigst, ist die VM wirklich gelöscht und da wollen wir hier nicht. Also nur VM aus dem Inventar löschen.
Du kannst vorher auch einfach den VM-Ordner unter Windows bzw Linux an den neuen Speicherort verschieben und erst dann die VM aus dem Inventory nehmen.
Um die VM am neuen Speicherort wieder im Inventory zu registrieren, kannst du dich entweder in der WS-Anwendung über Datei/File, Öffnen/Open und dem sich darauf öffnenden Fenster über Durchsuchen/Browse an den neuen Speicherort durchhangeln oder die VM einfach vom dort per Doppelklick auf die VMX-Datei starten. Das sich daraufhin öffnende Fenster fragt dich dann nur, ob die VM kopiert oder verschoben wurde und ob dies als Voreinstellung genommen werden soll. Die Voreinstellung würde ich sein lassen und nur Verschoben anklicken. Das war's dann auch schon...