ans hat geschrieben: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.
ans hat geschrieben:Dayworker hat geschrieben: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.