Guest Host 2008 srv std. x64 performance im Keller

[cmue]

Hallo,
wir betreiben hier einen debian Server auf dem VMWare 2 installiert ist. Das Hostsystem hat 2 Quadcores und 16GB Speicher. Aktuell laufen 5 VM's gleichzeitig, die sich mehr oder weniger langweilen, auch die htop auf dem Host zeigt nur Schäfchen zum Zählen an. Also Hardwaretechnisch alles entspannt.

Das Problem: wir haben einen 2008er Std. x64 am laufen und es ist einfach nicht auszuhalten, wie derbe langsam die Maschine ist. VMWare Tools aktuell, 50% freier zugewiesener Arbeitsspeicher und 1 CPU. Booten dauert ewigkeiten, arbeiten ist gar nicht möglich, da jeder Button klick bis zu 30sek zum Reagieren braucht.

Gibt es ähnliche Erfahrungen von euch? Hat jemand einen Tipp?

[continuum]

lad mal das letzte vware.log der Schlaf-V bei http://ifile.it hoch

[cmue]

Dein Dienst klappt gerade nicht, daher:
http://dl.dropbox.com/u/6298663/vmware.log

[Dayworker]

Das die VMware-Tools aktuell sind, halte ich ja für ein Gerücht. Der VMserver2 ist seit Januar 2010 "end-of-availability" und hat auch davor nur selten ein Update erfahren. Die VMware-Tools vom Server2 haben daher denselben unschönen Bug wie alle ungepatchten ESX(i)4.0 im Zusammenhang mit allen Win-OS seit Vista. Das Treibermodell hat sich dort geändert und über die VMware-Tools werden nachwievor die Treiber für alle Win mit Stand von pre-Vista installiert. Während das bei Maus und Tastatur kein Problem ist, geht das bei der Grafik voll nach hinten los. Du erkennst den falschen Treiber an der Anzeige im Gerätemanager deines Win-Gastes, wenn dort noch "VMware SVGA II" als Graka vermerkt ist. Die Lösung beim ungepatchten ESX(i)4.0 sah dort die De-Inst/Rollback auf den Grafiktreiber von M$ vor. Nur wenn dort etwas mit "VMware 3D" oder "WDDM" im Namen aufgeführt ist, wurde der richtige Treiber installiert. VMware hat dazu auch einen KB-Eintrag WDDM and XPDM graphics driver support with ESX 4.0 Update 1, Workstation 7.0, and Fusion 3.0 verfaßt. Allerdings hilft dir das beim VMserver2 höchstwahrscheinlich nicht weiter, keine Ahnung ob die VMware-Tools von der Workstation hier lauffähig sind.

[add]
Das dein VMserver noch die uralte Version 2.00 hat, ist dir aber hoffentlich bewußt. Neben einigen Sicherheitslücken sind dort noch jede Menge Bugs enthalten...

[continuum]

Keine weiteren Fragen

Punkt 1: prefvmx.minVmMemPct = 25

stell das sofort auf 100 - sonst brauchst du dich nicht wundern


Punk 2: du hast jede menge Eintraege a la
vmx| scsi0:0: Command WRITE(10) took 1.001 seconds (ok)

Grund: du verwendest monolithicSparse vmdks die du evtl noch nie ? - geshrinkt hast ???

[Dayworker]

Punk 2: du hast jede menge Eintraege a la
vmx| scsi0:0: Command WRITE(10) took 1.001 seconds (ok)
vmx| scsi0:0: Command READ(10) took 43.110 seconds (ok)

Die sind anscheinend völlig normal, zumindest habe ich nicht gegenteiliges im VMTN gefunden. Ich hab diese sogar bei Preallocated Disks mit bis zu 15sec sowohl bei VMserver1 und 2. Kommt immer drauf an, was der Host sonst noch "nebenbei" (andere Anwendungen wie weitere VMs) zu erledigen hat und der Host hat in IO-Fragen logischerweise immer Vorfahrt. Schlimm wirds erst, wenn so wie in dem Log zu einem späteren Zeitpunkt, Eintrage auftauchen mit:

Aug 16 14:14:16.036: vmx| DISKLIB-LIB : numIOs = 50000 numMergedIOs = 6377 numSplitIOs = 720
Aug 16 15:39:45.036: vmx| scsi0:0: numIOs = 60957 numMergedIOs = 7579 numSplitIOs = 830 ( 9.9%)

Dann ist Handeln gefragt. Während die "numIOs = 50000" noch eine normale Zählung der IO-Zugriffe in Tausender Schritten sind, wenn auch schon mit normalerweise besser nie auftauchender Fragmentierung, ist bei "numIOs = 60957" ein Problem, erkennbar an der ungeraden Angabe der "numIOs" und zusätzlich "(9.9%)", aufgetreten. Da ist unbeabsichtig eine Fragmentierung passiert, höchstwahrscheinlich weil der Plattensektor schon belegt war und ein Ausweichssektor angesteuert werden mußte. Auf einem VMserver1 hab ich trotz diverser Versuche mit Sparse-Disk dieses Verhalten aber nie erzwingen können. Entweder ist das ein weiterer Bug des VMserver2 oder die v.Disk war auf meinem VMserver1 sehr weit hinten und mit viel Freiraum davor auf der Platte gelandet. Die Lösung liegt meist im Shrinken und falls das nicht ausreicht, kopiert man die VM auf einen anderen Datenträger mit ausreichend Platz und wieder Retoure.

Aug 16 11:18:35.855: vcpu-0| The guest OS tried to update the CPU's microcode.
Aug 16 11:18:35.855: vcpu-0| Since a newer microcode version exists, please consider updating the microcode on your host.

Sowas ist viel ärgerlicher. Verbesserungen bzw Neuerungen am Microcode der CPU sind vielfach mit Ansteuerungsänderungen des Energiemanagements verbunden. Auf Laptops sinkt damit meist der Stromverbrauch der CPU und der Akku hält länger.