Unregelmäßig sehr langsam (WS 8.0.4 unter W8-64; Gast W7-64)

[ans]

Ich verwende VMWare Workstation (8.0.4 build-744019) unter Windows 8 Professional 64 Bit [MSDN], Gastbetriebssystem ist ein Windows 7 Professional 64 Bit - Ein Image das bereits unter meiner vorherigen Windows 7 Installation im Einsatz war.

Nun ist es so, das unregelmäßig, aber doch recht häufig [fast 50%], das der Start dieses Images nun statt unter 1 Minute ca. 15 Minuten zum Starten braucht. In diesem Fall ist zudem mein Prozessor zu 100% ausgelastet (AMD Phenom II X6 1090T 3.20 GHz), so das ein paralleles Arbeiten auch nur sehr eingeschränkt möglich ist.

Sobald das Windows-Login erscheint, scheint es aber keine weiteren Einschränkungen zu geben (Vorher hängt auch die Darstellung der Mini-Animation des Windowslogos massiv).

Hat jemand Anderes bereits ein änliches Phänomen bemerkt, und weiß ob der Wechsel auf Version 9 dieses Problem behebt, bzw. ob es eine Problemlösung gibt?

[Dayworker]

Verlinke mal entweder eines der "vmware.log" aus dem VM-Ordner oder poste mehr Details zur VM-Ausstattung bezüglich vRAM, vCPU(s) und vDISK (preallocated, sparse).

[continuum]

Hat jemand Anderes bereits ein änliches Phänomen bemerkt, und weiß ob der Wechsel auf Version 9 dieses Problem behebt, bzw. ob es eine Problemlösung gibt?

Symptom: unregelmaessig, nicht reproduzierbare Langsamkeit bei hoher Auslasting des Hosts ?

Habe ich auch seit WS 8 - selbstr wenn mal alle Tweaks kennt kriegt man das nicht weg.

Mit WS 9 wird das leider nicht besser.

Es kann natuerlich trotzdem sein dass du unguenstige Einstellungen nimmst ... deswegen zeig uns mal ein vmware.log

[ans]

Wie bei dem typischen Zuschauereffekt hatte ich dieses Problem bis zum Posten in diesem Forum relativ regelmäßig (etwa jedes 2te mal), seither aber noch nicht wieder.

vmware.log & vmx-Datei (zip)

Wesentliche Eckdaten:
- 3.0 GB Ram (Host hat 8GB)
- 1 Prozessor, 6 Cores (Wie Hostsystem)
- HDD1: Aktuell 21,1GB, Max 24GB
- HDD2: Aktuell 3,6GB, Max 10GB

[Dayworker]

Wesentliche Eckdaten:
- 3.0 GB Ram (Host hat 8GB)
- 1 Prozessor, 6 Cores (Wie Hostsystem)
- HDD1: Aktuell 21,1GB, Max 24GB
- HDD2: Aktuell 3,6GB, Max 10GB

In der Virtualisierungswelt gilt die Devise: "Nur soviel wie nötig und nicht wie möglich."
Wenn du einer VM dieselbe Anzahl an Kernen wie dem Host gibst, wo soll dann noch Rechenzeit für das Host-OS übrigbleiben? Damit bremst du nur das gesamte System aus...
Einem Desktop-Virtualisierer von VMware mehr als 1 oder 2GB vRAM zu geben macht auch nur wenig Sinn. Je nach WS-Version wird ab einer bestimmten vRAM-Grösse nur noch ein minimaler Grundwert an vRAM im Host-RAM gehalten (meist 500MB) und der Rest wird dem Host-OS als auslagerungsfähig gemeldet. Dieser Bitte kommt das Host-OS umgehend nach und die Geschwindigkeit in der VM sinkt, da jede RAM-Anforderung im Gast erst zu einer HDD-Aktivität im Host führt. Dieser muß das ausgelagerte vRAM der VM erst wieder in den RAM laden...

Als Krönung hast du dann auch noch Sparse-Disks konfiguriert. Bei Schreibanforderungen im Gast verteilt sich dann dessen vDISK über die komplett Host-Disk und fragmentiert dadurch recht zügig. Sowas läßt sich mit Preallocated Disks vermeiden. Da bei vDISK aber dasselbe "weniger ist mehr" gilt und du eine vDISK auch nicht so einfach verkleinern kannst (vergrößern geht einfach), stellen Preallocated Disk bei vernüftiger Platzplanung eigentlich kein Problem dar.

[ans]

Wenn du einer VM dieselbe Anzahl an Kernen wie dem Host gibst, wo soll dann noch Rechenzeit für das Host-OS übrigbleiben? Damit bremst du nur das gesamte System aus...
Einem Desktop-Virtualisierer von VMware mehr als 1 oder 2GB vRAM zu geben macht auch nur wenig Sinn.

Da ich hauptsächlich unter der VM arbeite (Softwareentwicklung), sehe ich das hier Anders*. Zudem lief es bis einschließlich Windows 7 64 als Host ohne jegliche Probleme.

* Da die Entwicklungsumgebung jeden Kern auslastet hat dies zu massiven Senkungen beim Compilieren geführt (Ich hatte eine vergleichbare Konstellation schon mit 1, 2 und 4 Kernen getestet).

Als Krönung hast du dann auch noch Sparse-Disks konfiguriert.

Das kann ich ändern, nur hatte in der Vergangenheit einiges dazu geführt das ursprünglich großzügig bemessener Platz nach den diversen Servicepacks usw. eben doch nicht mehr so großzügig ausfiel. Aber auch dies war unter dem vorherigen Host auch kein Problem.

[PeterDA]

Hi,
du solltest dir aber mal überlegen was wohl passiert wenn deine VM so viele vCPUs/vCores hat wie dein Host und die auch alle ausnutzt und dann der Host doch mal was machen muss. Wie soll das denn gehen? Hinzu kommt, dass deine VM ja immer nur dann eine Rechenoperation durchführen kann, wenn sie sich ALLE CPUs und Cores des Host resevieren kann, egal ab sie alle braucht oder nicht.

Gruß Peter

[continuum]

Windows 8 als Host ist bei WS 8 gar nicht supportet - und bei WS 9 muss man es auch als eher experimentell einstufen

[Dayworker]

Da ich hauptsächlich unter der VM arbeite (Softwareentwicklung), sehe ich das hier Anders*. Zudem lief es bis einschließlich Windows 7 64 als Host ohne jegliche Probleme.

* Da die Entwicklungsumgebung jeden Kern auslastet hat dies zu massiven Senkungen beim Compilieren geführt (Ich hatte eine vergleichbare Konstellation schon mit 1, 2 und 4 Kernen getestet).

Wenn es dir um maximale Leistung geht, bist du mit Virtualisierung völlig falsch aufgestellt.
Alle Desktop-Virtualisierer können für ihre VMs nicht mehr als 75% des verfügbaren Gesamtsystemleistung abrufen, den Rest schluckt immer das Host-OS. Beim schlanken ESXi mit seinem an Virtualisierung angepaßten Unterbau sind dagegen bis zu 95% erreichbar. Der Preis dafür ist seine nur bedingt taugliche HW-Kompatibilität.
Bei dir kommen dann noch hinzu, daß du zuallererst ein unsupportetes Host-OS einsetzt (kann aber muß nicht funktionieren, Nebenwirkungen gab es bisher immer in solchen Fällen) und bei der Menge an vRAM auch die Erstellung einer vMEM-Datei gleicher Grösse nicht unterbindest. Vor jedem VM-Start werden also erstmal 3096MB physisch auf den Host-Datenträger geschrieben und auf Funktionalität/Zuverlässigkeit überprüft. So wie ich die Lage einschätze, wirst du ebenfalls einen Virenscanner einsetzen und diesem keine Ausnahme für den deine VMs enthaltenden Ordner gemacht haben. Ergo werden die vDISK(s) beim Aufruf erstmal gesperrt und gescannt. Falls eine VM bereits läuft, sind dann Abstürze mangels Datenträger nichts ungewöhnliches.

Als Krönung hast du dann auch noch Sparse-Disks konfiguriert.

Das kann ich ändern, nur hatte in der Vergangenheit einiges dazu geführt das ursprünglich großzügig bemessener Platz nach den diversen Servicepacks usw. eben doch nicht mehr so großzügig ausfiel. Aber auch dies war unter dem vorherigen Host auch kein Problem.

Sparse-Disks werden immer zum Problem, wenn man diesen keine Wartung in Form von manuellem Shrinken angedeien läßt. Sparse-Disks fragmentieren sich bei Schreibzugriffen, und dazu zählen auch Defragmentierungsläufe im Gast-OS, die überdies die vDISK auch auf deren volle Grösse aufblasen, über den kompletten Host-Datenträger und werden deshalb auch anfälliger für damit zusammenhängende Probleme. VMware hat meines Wissens nach im Gegensatz zu M$' VPC bzw Hyper-V bisher nur in sein Mac-Produkt Fusion5 eine Shrink-Automatik vorgesehen. Bei VM-Shutdown wird dabei die Luft aus der vDISK gelassen, was je nach Grösse von vDISK und geschriebenen Datenvolumens sowie Geschwindigkeit des Host-Datenträgers entsprechend lange dauern kann. Das mußt du in WS/Player bisher regelmäßig manuell anstossen und in Abhängigkeit zum geschriebenen Volumen innerhalb der VM ist wöchentliches Shrinken keine schlechte Idee. Falls du irgendwann mal ein mir unbekanntes Limit überschreitest, wirst du darauf eh vom VMware-Produkt freundlich hingewiesen und die VM wieder abgeschaltet.
Es spricht also nichts dagegen, auf Preallocated Disks zu setzen. Die können zwar bei unzureichendem Platz auf dem Host auch fragmentiert gespeichert werden, aber wenigstens bleiben die vDISK-Fragmente, unabhängig ob darin geschrieben oder nur gelesen wird, immer am selben Platz gelagert.
Da du bei Sparse-Disks immer mit dem schlimmsten Fall ergo der maximalen vDISK-Grösse rechnen mußt, muß der Platz auf der Host-Disk eh vorhanden sein oder die VM stürzt ab. Preallocated Disks ersparen dir das, sie können nicht grösser als ihre angelegte Grösse werden und vergrössern lassen sich beide Typen in zwei Schritten. Einer davon über die GUI, Grösse der vDISK für VMware ändern, und der zweite in der VM um die Partition zu vergrössern. Den entgegengesetzten Weg hat VMware dagegen weder über die GUI noch auf der CMD/ba$h vorgesehen und es sind andere Mittel wie Converter oder das vDISK-Format unterstützende Partitionierer gefragt.