Generell eines vorweg, die absolut optimale Konfiguration gibt es nicht. Sie ist meist stark Anwendungsabhängig und jede VM braucht im Normalfall (Ullis MOA, Linux-Live-Systeme, Win/Bart-PE usw mal außen vor) auch ihren Diskzugriff. Da kann man nichts dran ändern, ABER man kann den Disk-IO auf ein Minimum reduzieren und damit die Hostleistung besser für die Gäste verfügbar machen. Wer halt immer noch etwas mehr braucht, muß sich doch mit dem ESX(i) und seiner HCL (HW-Kompatibililililililililitäts-Liste) anfreunden.
Für die bestmögliche Rechenleistung sollte der Host möglichst immer einen Kern mehr als gestartete VMs haben, schließlich braucht das Host-OS auch noch etwas für seine Belange. Wenn sich dazu mindestens 512MByte für 32bittige und 1GByte für 64bittige Host-OS gesellen, kann der Rest an physischen RAM problemlos für VMware reserviert werden. Per Default reserviert VMware max 90% des verfügbaren Host-RAMs für sich, daß kann aber manchmal schon zuwenig für den Host sein. Also verändert man bei Notwendigkeit das per Web-Access oder VI-Client in den Memory-Einstellungen des Hosts. Dabei gibt es noch 3 Möglichkeiten auf die Verteilung des Host-RAMs Einfluß zu nehmen, wobei Punkt 1 eindeutig zu bevorzugen ist:
- Fit all virtual maschine memory into reserved host RAM
- Allow some virtual maschine memory to be swapped
- Allow most virtual maschine memory to be swapped
Den darunter befindlichen Hinweis von VMware sollte man wörtlich nehmen und ist selbsterklärend:
“Swapping virtual maschine memory allows more virtual maschines to run but can degrade system performance if the virtual machines us their memory intensively.”
Kommen wir mal zu den virtuellen HDDs.
Neue Disks legt man, immer ausreichend Platz voraus gesetzt, bevorzugt als "Preallocated" an. Das bedeutet, daß das Disk-File nach dem Anlegen schon den kompletten Speicherplatz vorbelegt. Das bringt vor allem beim Schreiben und auch beim Lesen Geschwindigkeitsvorteile in der VM, da die v.HDD am Stück (Stichwort Defragmentierung) vorliegen dürfte und ihre Datei-Fragmente (*.vmdk) daher nicht quer über die Host-HDD einsammeln muß. Der Split in 2GB ist eigentlich nur notwendig, wenn das Filesystem nicht mit größeren Dateien umgehen kann. Es erleichtert jedoch auch das Backup einer VM. 2GByte als Datei kann man noch bequem auf DVD/BD/HDVD sichern, bei 100GB bleibt dem Normalanwender momentan leider nur noch die HDD als kostengünstigstes Medium übrig.
Weiterhin gibt es für jede v.HDD auch noch 2 Einstellungen im Schreibverhalten der VM, die Optimierung auf Performance und die Optimierung auf Sicherheit. Beide lassen sich in meinen Augen recht einfach erklären, Performance = Write Back (Schreibenanforderungen werden zurückgehalten, bis entweder Zeit dazu oder der Zwischenspeicher/Cache voll ist) und Sicherheit = Write Thru (Schreibenanforderungen werden direkt durchgereicht).
Der Independent Mode kommt dann auch noch dazu. Dieser Teil wird später nachgereicht.
Eine für die Gäste optimalere "config.ini" könnte daher wie folgt aussehen:
Auf Linux-Host wird da schon mal in der Datei /etc/sysctl.config der Parameter vm.swappiness=0 gebraucht und dazu gesellen sich unter Linux & Windows dann noch die folgenden Zeilen in die Config-Datei:
MemAllowAutoScaleDown="FALSE"
mainMem.useNamedFile = "FALSE"
mainMem.partialLazyRestore = "FALSE"
mainMem.partialLazySave = "FALSE"
sched.mem.pshare.enable = "FALSE"
Dazu würde ich auch noch: mks.enable3d = "FALSE" aufnehmen, denn 3D-Support gibt weder im Server1 noch im Server2 sondern lediglich in Workstation oder Player.
Die Config-Datei ansich befindet sich dann unter:
Linux - "/etc/vmware/config"
oder
Windows - "Documents and Settings\All Users\Application Data\VMware\VMwareServer\config.ini" bzw
"Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten\VMware\VMwareServer\config.ini"
Für Linux-Hosts mit wenig pRAM macht sich wohl auch eine SSD sehr gut. Im Thread VMWare-Maschine "schläft ein" schrieb Ronny dazu:
“Ich habe gestern mal eine 64 GB SSD (SATA2) in mein System eingebunden (siehe Signatur) und dort auf einzelnen Partitionen Swap (12 GB), /var/tmp (6 GB), /tmp (29 GB) und /dev/shmfs (12 GB) - was ich mir wahrscheinlich hätte sparen können - eingerichtet. Dann habe ich dem VMware Server erlaubt, einigen vRAM auszulagern, und habe noch eine VM gestartet.
Fazit:
Die Auswirkungen gleich nach dem Start sind minimal, mir ist aber sehr geringes o.g. Einschlafverhalten aufgefallen (die VMs reagierten heute morgen ca. 1 Minute etwas träge). Eine SSD scheint als Tuning für einen Linux-Host bei zu wenig RAM, ganz gut zu funktionieren.”