VMware Workstation 7.x eignet sich zur Virtualisierung verschiedener Betriebssysteme unter Windows 7. Dabei werden auch 64-Bit-Gastbetriebssysteme unterstützt. Ärgerlich ist es aber, wenn es Performanceprobleme gibt. Der Beitrag geht auf einige Fallstricke ein.
Ich habe gerade mal im Bücherschrank nachgesehen. Mein erstes Buch zu VMware Workstation kam 2001, also vor einem Jahrzehnt, heraus. Damals erfolgte die Virtualisierung unter Windows XP mit 450 bzw. 800 MHz Prozessoren und 500 MByte Arbeitsspeicher. Gastbetriebssysteme waren DOS, Windows 9x und Windows XP. Und alles lief irgendwie halbwegs. Seit dieser Zeit sind die Rechner bzw. die Prozessoren schneller geworden. Zudem stehen mittlerweise Quad-Core-Prozessoren mit VT-Unterstützung zur Verfügung. Nach der Theorie sollten sich daher Betriebssysteme in VMware Workstation problemlos und ohne Performanceverluste virtualisieren lassen. Die Praxis spricht aber eine andere Sprache: Immer wieder habe ich mit Performanceproblemen, bei denen der Host oder einzelne Anwendungen kurzzeitig einfrieren oder die Gastbetriebssysteme zäh laufen, zu kämpfen. Zeit, einen Blick auf die Details zu werfen und zu analysieren, wo es hängen kann.
Mangelnder Arbeitsspeicherausbau
Ein gravierendes Problem ist der Speicherhunger von Windows 7, der gerade bei 64-Bit-Host-Betriebssystemen zum Tragen kommt. 64-Bit-Systeme, die mit 4 GByte Arbeitsspeicher ausgestattet sind, können zwar noch ein Gast-Betriebssystem mit 1 GByte Arbeitsspeicher virtualisieren. Aber spätestens beim zweiten Gast-Betriebssystem, welches gleichzeitig läuft, wird es schwierig [4]. Auf dem Host bleibt nicht genügend freier Arbeitsspeicher zurück, um dessen Betriebssystem performant zu betreiben. Daher sollten Maschinen zur Virtualisierung mit 6 GByte oder mehr Arbeitsspeicher ausgestattet sein.
I/O-Last zu hoch, Chipsatztreiber als Bremse
Die zweite Schwachstelle, die die Leistung der virtuellen Maschinen ausbremsen kann, ist die I/O-Kapazität für Plattenzugriffe. In diesem Bereich erlebe ich immer wieder Reinfälle. Unter [6] diskutiere ich den Fall eines QuadCore-Systems mit 4 GByte RAM, auf dem immer wieder Hänger und Mikroruckler bei Anwendungen oder auf dem Windows-Desktop auftraten. In den Programmfenstern erscheint dann der Hinweis “keine Rückmeldung”, der aber nach einigen Sekunden verschwindet. Eine Analyse mit dem Ressourcenmonitor ergab seinerzeit, dass die Prozesse auf “E/A-Anweisungen” warteten.
Im hier genannten Fall ließ sich das Problem durch korrekte Installation der benötigten Windows 7-Chipsatztreiber schlussendlich lösen. Falls aber eine höhere I/O-Last im System auftritt, kann eine Begrenzung der Diskzugriffe zu Performanceeinbußen bei der Virtualisierung führen [2]. In diesem Fall lässt sich das Ganze mittels des Windows-Ressourcenmonitors überwachen. Zudem kann das Programm IOMeter eingesetzt werden, um die I/O-Rate des Hosts zu testen. Kommt es zu I/O-Performance-Engpässen, ist es in manchen Fällen hilfreich, die Dateien der virtuellen Maschine auf eine Festplatte zu legen, die an einem separaten SATA-Kontroller hängt.
Konfigurierung der Gast-Umgebung
Eigentlich ist es naheliegend, bei einem Dual- oder QuadCore-Prozessor dem Gast-Betriebssystem alle Kerne zuzuteilen. Dann können Host und Gast sich die Rechenpower aufteilen. In der Praxis hat es sich aber herausgestellt, dass es für den Hypervisor der Virtualisierungssoftware günstiger ist, wenn der virtuellen Maschine nur ein Rechenkern (vCPU) zugeordnet wird [2].
Weitere Spassbremsen
Bei Systemen, deren Prozessoren eine VT-Unterstützung ermöglichen, kann eine im BIOS deaktivierte VT-Unterstützung die Ursache für eine schlechte Performance sein. Ein weiteres Augenmerk sollte man auf Virenscanner werfen. Je nach Produkt kann es sein, dass dieses die Dateien mit den virtuellen Disks ständig überprüft und so zu Performanceeinbußen führt. Hier lassen sich die .vmdk-Dateien der VMware Maschinen von einer Prüfung ausnehmen.
Windows 7 Service Pack 1 bereitet Ärger
Die obigen Punkte waren mir irgendwie alle bekannt und eigentlich hatte ich ein Windows 7 Ultimate (64-Bit) so eingerichtet, dass eine Virtualisierung unter VMware Workstation 7.1.2 bzw. 7.1.3 mit zwei VMs (1 x Windows XP-Mode und 1 x Windows 7 Home Premium 32 Bit) ganz passabel lief.
Weil ich mir aber irgendwann das Host-Betriebssystem durch einige Softwaretests etwas ramponiert hatte, dass Systembackup aber doofer Weise einen Fehler enthielt, der beim Zurücksetzen einige Reparaturschritte erforderte, beschloss ich, eine Neuinstallation des Hosts durchzuführen.
Und weil gerade das Service Pack 1 für Windows 7 veröffentlicht worden war, habe ich gleich Windows 7 Ultimate 64 Bit mit integriertem SP1 aus dem MSDN-Downloadbereich zur Installation verwendet. Obwohl ich bei der Installation peinlich darauf achtete, dass die Chipsatztreiber in der korrekten Reihenfolge installiert wurden, wurde ich mit dieser Installation nicht glücklich. Das reine Windows 7 lief mit Anwendungsprogrammen problemlos. Aber sobald VMware Workstation 7.1.4 gestartet wurde, lief das Gastsystem gefühlt wesentlich zäher als vorher (auch wenn unter [4] erwähnt wird, dass das Problem in dieser VMware Workstation-Version angeblich behoben sei). Zudem machte sich auf dem Host der Effekt bemerkbar, dass Anwendungen wie Firefox, Thunderbird, Internet Explorer etc. immer wieder kurzzeitig “… reagiert nicht mehr” in der Titelleiste des Anwendungsfensters zeigten. Die Analyse mit dem Ressourcenmonitor ergab, dass I/O-Prozesse warten mussten.
Nach einigen Versuchen verdichtete sich das Bauchgefühl, dass es mit der Kombination Chipsatztreiber und Service Pack 1 zusammen hängen könnte. Bei der Suche bin ich dann auf die unter [3, 4, 5] verlinkten Webbeiträge gestoßen, die die Ursache ziemlich genau benennen. Im Service Pack 1 für Windows 7 und Windows Server 2008 R2 hat Microsoft eine neue Speicherverwaltung (Dynamic Memory) für VMs unter Hyper-V eingeführt. Nach der Installation des SP1 auf einem Windows 7-Host kann es zu Problemen bei der Speicherzuweisung und Performanceeinbußen kommen. Der Beitrag unter [5] bezieht sich auf VMware Workstation 7.1.3. Aber auch in der 7.1.4 konnte ich die verringerte Performance feststellen. Im Beitrag wird vorgeschlagen, die Konfiguration folgendermaßen anzupassen.
- Rufen Sie den Windows-Editor über den Kontextmenübefehl Als Administrator ausführen auf.
- Laden Sie die Datei config.ini aus dem Verzeichnis C:\ProgramData\VMware\VMware Workstation\ in den Windows-Editor.
- Anschließend fügen Sie an das Ende der Konfiguration die neue Zeile vmmon.disableHostParameters = „TRUE“ ein.
Nach dem Speichern der Änderungen ist Windows 7 neu zu starten. Die Änderung wirkt sich auf die Speicherzuordnung aus und hat den Nachteil, dass die virtuellen Maschinen etwas mehr Speicher belegen. Aber zumindest auf meinem System habe ich den Eindruck, dass die Performanceprobleme zumindest reduziert wurden. Optimaler ist es aber, einen Windows 7 Host ohne installiertes SP1 zur Virtualisierung mit VMware Workstation zu verwenden.
Links:
1: VM’s hang (VMware Forendiskussion, Englisch)
2: VMWare slow performance
3: VMware Workstation 7.1.3 and Windows 7 SP1
4: Go Slow: VMware Workstation 7 and Win7 SP1
5: FIX: Poor VM Performance & Errors with VMware Workstation 7.1.3
6: Ständige “Freezes” in Windows 7
7: A user’s guide to Iometer
Update: Irgendwie ist es mir aus dem Radar gefallen – und im obigen Artikel in einem Nebensatz untergegangen. Die massiven Performance-Probleme, die sich sogar auf die Leistung des Hosts auswirkten (dieser war zeitweise bei zwei VMs nicht mehr bedienbar) ließen sich lösen, indem ich die VMs auf eine separate SATA-Platte verschoben habe.
Diese Trennung von Host-Betriebssystem-Speichermedium und Speichermedium für VMs wird faktisch von keiner Virtualisierungslösung beachte. Alle „nageln gnadenlos“ den Pfad zur Ablage neuer VMs in den Profilordner des Benutzers rein – und damit nutzt das Gastbetriebssystem die Disk-I/O-Kanäle des Hosts mit. Seit ich die VMs auf einer separaten SATA-Festplatte halte, kann ich auch zwei VMs problemlos parallel ablaufen lassen.
Hallo Günther,
ein weiterer Grund für den ‚kein Verbindung‘-Fehler bei VM kann auch die falsche Wahl des S-ata Ports sein. In meinem Fall hing die S-ata Platte auf denen die VM’s liegen am S-ata3 Port, obwohl die Platte nur eine S-ata2 Platte ist. Erst nach dem umstöpseln auf den richtigen Port wahren die Probleme verschwunden. Vermutlich hätte auch ein besserer Treiber für S-ata3 die Probleme behoben. In Version 9 von VMWare bin ich mir zudem nicht sicher ob S-ata 3 nativ unterstützt wird. Kommende Versionen werden damit besser umgehen können. Gruß Ralf
@Ralf: Danke für das Feedback – ich nutze kein VMware Workstation 9. Hilft aber vielleicht dem einen oder anderen VMware-Nutzer.