1 VM ist gähnend langsam ...

[drnicolas]

Ich beobachte seit einiger Zeit, daß eine bestimmte VM unter Windows 7 Ult. ungewöhnlich langsam ist.
Erst dachte ich, es könnte an einem persistierenden Snapshot liegen ,aber daß scheint nicht der Fall zu sein.
Die Problematik beginnt schon mit dem Bootvorgang. Auch im Betrieb ist alles sehr zäh.

Auch der Wechsel auf die VMXNET3 hat keine Besserung gebracht.

Ich weiß, die Angaben sind mehr als vage, aber mir fällt nichts konkreteres ein.

Kennt jemand typische Probleme, die sowas verursachen können?

[Dayworker]

Hast du Reservierungen vorgenommen?
Ist die VM die einzigste im DS?
Wurde der DS von vSphere4 übernommen?

Stichwort Dell PERC 6/i:
BBU vorhanden?
BBU vielleicht leer und daher der Cache deaktiviert?
Welches Raid-Level? Raid runtergestuft wegen temporären oder kompletten Plattenausfall?

[drnicolas]

1. Die VM auf einem RAID5 des Dell PERC 6/i
2. es ist nicht die einzige VM dort
3. VMs auf einer SSD scheinen weninger betroffen zu sein
4. der Dell PERC wird als "optimal" bezeichnet"
5. die BBU hat 99% charge
6. die betroffene VM hat eine Reservierung von 1024MB
7. es gibt noch eine weitere VM (auf SSD), die eine MHz-reservierung hat.

8. keiner der DS wurde meines Wissens von V4 übernommen, sondern erst mit V5 erstellt.

[Dayworker]

Der Controller meldet "optimal". Gilt das nur für den momentanen Zustand oder werden im Log dazu noch andersweitige Einträge geschrieben?
Wenn es bei Schreiben und erst recht beim Lesen auf einem Raid5 zu Verzögerungen kommt, würde ich mir die Raid5-Teilnehmer mal genauer ansehen.

Was heißt bei dir, "VMs auf einer SSD scheinen weninger betroffen zu sein"?
SSDs sind normalerweise immer schneller. Wenn diese jedoch auch nicht ihre volle Leistung bringt, hat vermutlich der Controller ein Problem.

[drnicolas]

Die Meldung stammt vom ESX.
Unter Windows 7 kann ich noch mit dem LSI MegaRAID-manager nachschauen und auch der meldet das RAID als okay.

Natürlich empfinde ich die Geschwindigkeit der VMs immer als zu langsam.
Aber bei diesem Rechner ist es doch sehr zu spüren.

[Dayworker]

Ein Raid5 bremst beim Schreiben immer. Wenn du deine VMs mit viel vRAM ausgestattet hast, ist das ungünstig, da beim VM-Start eine vswap-Datei gleicher Grösse angelegt wird und je nach vRAM-Grösse dauert das dann halt entsprechend.

Lad mal bitte irgendwo das "vmware.log" hoch, falls dein AG nichts dagegen hat. Vielleicht wissen wir dann mehr.

[drnicolas]

Sollte kein Problem sein,
Theoretisch. Ich habe mal die VM runtergefahren und die sehr großen .log-dateien gelöscht.
In der Annahme es würde wieder neue Dateien angelegt.
Aber nach dem Hochfahren war keiine neue .log-Datei da!

Wann kommt die neue Datei ?

[Dayworker]

Du meinst hoffentlich nur die Dateien mit "vmware-XYZ.log". Wenn du eine VM startest, werden wieder ein neues "vmware.log" angelegt.
Wenn du eine VM gestartet, dich darin als Benutzer angemeldet hast und trotzdem kein Log angelegt wird, würde ich die VM-Config und dort den Speicherort mal genauer ansehen. Nicht das du im falschen Verzeichnis gelandet bist. Sowas kann schnell mal übersehen werden, wenn du die vDISKs einer VM über mehrere DS aus Platz- oder Performancegründen verteilst.

Sieh dir auch mal den KB-Eintrag Locating virtual machine log files on an ESXi/ESX host (1007805) und dort die Weiterführung auf Log rotation and logging options for vmware.log (8182749) an. Du kannst darüber sowohl das Log-Verzeichnis als auch das Anlegen eines Logs beeinflussen.

[drnicolas]

Wie ulkig!
Die VM läuft einwandfrei, aber keine neue .vmware*.log wurde angelegt.
Die Methode aus der KB ergibt den normalen Pfad.

[mbreidenbach]

Was hat der ESXi and RAM und CPU ?

Wieviel davon ist an VMs vergeben ?

Sind bei den VMs Reservierungen oder Limits für CPU oder RAM gesetzt ?

Ist die Aussagen 'ist langsam' bisher irgendwie durch Meßwerte belegbar ?

Schon mal CPU Ready % untersucht ?

http://kb.vmware.com/kb/2002181 Converting between CPU summation and CPU % ready values (2002181)
http://kb.vmware.com/kb/2001003 Troubleshooting ESX/ESXi virtual machine performance issues (2001003)
https://communities.vmware.com/docs/DOC-3930 Performance Monitoring and Analysis

Wenn ein 'virtuelles Desktop' gefühlt lahm ist würde ich mir als erstes CPU Ready % und Storage Performance ansehen.

[drnicolas]

Unter CPU-Nutzung ist angegeben: Wechselnd so zwischen 600 un 3600 MHz.
Arbeitsspeicher 15212 von 16284,75 MB

Alle Reservierungen sind beseitigt.

[Dayworker]

Um dir mal etwas bei der Einordnung nur deiner CPU-Nutzung zu geben, Realtime bedeutet bei VMware eine Aktualisierung alle 20 Sekunden. Wenn die CPU-Nutzung also auch Werte nahe an deinem maximalen CPU-Turbo von 3.8GHz anzeigt, muß da etwas über längere Zeit im Hintergrund laufen. Auf einem virtualisierten System sind das dann zu einem Großteil die anderen VMs, den kleinen Rest nutzt der ESXi selbst.

Bei einer Arbeitsspeicherbelegung von ~15GB bei 16GB installiertem RAM, könnte dem ESXi auch etwas Arbeitsspeicher für seine eigenen Belange fehlen. Daher sind wir an der Aufteilung der Host-Ressourcen auf die VMs interessiert und "mbreidenbach" hat dir genügend Material an die Hand gegeben.


Bezüglich deines fehlenden Logs sei dir gesagt, daß man die Log-Erstellung auch verhindern kann. Mit dem VMX-Eintrag logging="false" stellt man dies an oder ab und soweit ich weiß, wird dieser Eintrag nur nach einem VM-Neustart wirksam.

Hast du eigentlich eine stinomale Consumer-SSD am Laufen?
Falls ja sei dir gesagt, daß der ESXi vermutlich kein TRIM unterstützt. Damit könnte je nach SSD schon mal ein weiterer Grund für die immer schwächere IO-Performance vorliegen. Das einem Gast-OS jetzt mitgeteilt werden kann, daß es auf einer SSD residiert, hilft dem Host-OS dabei leider nicht weiter.

[drnicolas]

Die SSDs sind normale Modelle.
Bezügich RAM lässt dich sicherlich etwas machen.
DAs Logging schalte ich ein.Ich hoffe, ich muss nicht den ganzen ESX neu starten.