VMware-Forum

Hallo,

wir haben seit einiger Zeit das Problem, dass unsere Host-Rechner sich bei der Load langsam hochschaukeln. Dabei steigt der user-Anteil der CPU-Last kontinuierlich an (Attachment hätte ich gerne dran gemacht, aber er meint, das die 24,4 KB png-Datei zu groß wäre...)

Insgesamt haben wir dabei 3 Hosts im Einsatz.

Auf allen Hosts ist Debian Lenny installiert:
2.6.26-1-amd64 #1 SMP Mon Dec 15 17:25:36 UTC 2008 x86_64 GNU/Linux

Auf allen Hosts ist VMware Server 2 Build 122956 installiert

Die drei Hosts unterscheiden sich aber in der Hardware:
1) 1 Doppelkern-CPU: Intel(R) Xeon(TM) CPU 3.00GHz, 8 GB RAM
2) 1 Vierkern-CPU: Intel(R) Xeon(R) CPU X3220 @ 2.40GHz, 8 GB RAM
3) 2 Vierkern-CPUs: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 16 GB RAM
Wenn dazu weitere Infos hilfreich wären, reiche ich die gerne nach. Wichtig ist vielleicht noch, der erste hat keine Unterstützung für Virtualisierung im Befehlssatz der CPU, die beiden anderen haben und diese ist im BIOS auch aktiviert.

Die Hosts, die auf den System laufen wurden Ende letzten Jahres von VMware-Server 1 importiert (wir haben damals das Upgrade durchgeführt und seitdem das Problem).

Die Hardware Version der VMs ist generell noch 4, da wir im Zweifel zurück können wollten, die VMware-Tools sind in allen Maschinen auf dem Stand von Build 122956.

Die eingesetzten Guests sind hauptsächlich ebenfalls Debian Lenny-Maschinen, dazu kommt auf dem 1. Host ein Windows 2003 Server und ein Windows 2000 Server.

Als Test haben wir folgendes versucht:
- Alle Maschinen auf dem ersten Host wurden auf VMware Hardware Version 7 geupgradet -> Load schaukelt sich hoch
- Eine Maschine auf Host 3 wurde auf Hardware 7 geupgradet, der gesamte Host hat wachsende Load, die konkrete Maschine, die ebenfalls mit Munin überwacht wird, hat eine konstant niedrige Load.

Hat denn jemand schon etwas ähnliches mal festgestellt? Also Probleme mit ansteigender Load auf dem Host-Rechner nach Update auf VMware Server 2 ausgehend von dem 1er Server.

Könnte es auch damit zusammen hängen, dass die Virtualisierung auf einem Host nicht seitens des Chipsatzes unterstützt wird? Darauf deutet zumindest hin, dass die eine Maschine auf Host 3 keine steigende Load hat, während die Maschinen auf Server 1 sehr wohl diese steigende Load verzeichnen.

Bzw. sieht das Bild derzeit so aus:
Host 1 (keine Unterstützung, aber Hardware 7): Load auf den einzelnen Guests steigt und damit auch die Belastung des Hosts
Host 3 (mit Unterstützung, aber Hardware 4): Load auf den Guests ist konstant, aber die Load des Hosts an sich steigt dennoch stark an.

Zu einem Test, auf Host 3 alle Maschinen auf Hardware 7 zu bringen, können wir uns noch nicht durchringen, da das wichtigere Maschinen als auf Host 1 sind und wenn das Problem mit der hohen Load nicht lösbar ist, wäre es ein großer Aufwand, wenn wir hier wieder zum 1er Server zurück müssten, mit dem das Problem ja nicht bestand.

Wir oder ich sind für jeden Hinweis dankbar

Mit welche Einstellungen und welcher Last laufen denn alle VMs? Dazu wären Infos zu RAM, CPU-Anzahl, 32/64bit und sparse oder preallocated v.HDDs auch sehr hilfreich.

Aye, bei den Einstellungen müsste ich wissen, welche genau du meinst, ich versuche mal ein paar abzudecken.

Auf System 1 (1 Doppelkern-CPU: Intel(R) Xeon(TM) CPU 3.00GHz, 8 GB RAM, ohne Virtualisierungsunterstützung durch Chipsatz) laufen:
- Other Linux (32bit) -> Debian Lenny mit 256 MB RAM, 1 CPU, HDD SCSI wachsend (sparse?), durchschnittliche Load 0,1, Spitzen bis ca. 1
- Other Linux (32bit) -> Debian Lenny mit 512 MB RAM, 1 CPU, HDD SCSI wachsend (sparse?), durchschnittliche Load 0,2, Spitzen bis ca. 6
- Other Linux (32bit) -> Debian Lenny mit 512 MB RAM, 1 CPU, HDD SCSI wachsend (sparse?), durchschnittliche Load 0,1, Spitzen bis ca. 0,5
- Other Linux (32bit) -> Debian Lenny mit 256 MB RAM, 1 CPU, HDD SCSI wachsend (sparse?), durchschnittliche Load 0,1, Spitzen bis ca. 0,5
- Microsoft Windows 2000 Server 32 bit mit 512 MB RAM, 1 CPU, HDD SCSI wachsend (sparse?), durchschnittliche Last 2,5%, Spitzen bis ca. 10%
- Microsoft Windows 2003 Server Standard 32 bit mit 768 MB RAM, 1 CPU, 2 HDDs SCSI wachsend (sparse?), durchschnittliche Last 5-6%, Spitzen bis ca. 100%

alle VMs auf System 1 haben VMware Hardware Version 7

Auf System 3 (2 Vierkern-CPUs: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 16 GB RAM, mit Virtualisierungsunterstützung im Chipsatz) laufen:
- 3x Other Linux (32bit) -> Debian Lenny mit 256 MB RAM, 1 CPU, HDD SCSI wachsend
- 5x Other Linux (32bit) -> Debian Lenny mit 512 MB RAM, 1 CPU, HDD SCSI wachsend
- 2x Other Linux (32bit) -> Debian Lenny mit 768 MB RAM, 1 CPU, HDD SCSI wachsend
- Suse Linux (32 bit) mit mit 256 MB RAM, 1 CPU, HDD SCSI wachsend
- Windows XP Pro 32 bit mit 2048 MB RAM, 1 CPU, HDD IDE wachsend

Last:
- avg 0,1, Peak 0,5
- avg 0,05, Peak 0,3
- avg 0,2, Peak 2
- avg 0,1, Peak 4
- avg 0,05, Peak 0,5
- avg 0,6, Peak 6
- avg 0,1, Peak 1
- avg 0,1, Peak 2
- avg 0,1, Peak 0,5
3 System werden hier nicht überwacht.

alle VMs auf System 3 haben VMware Hardware Version 4, mit einer Ausnahme, die auf 7 geupgradet wurde.

Ansonsten haben wir die Standardeinstellungen in der vmx-Datei belassen, wie sie bei Erstellen der VMs vorgegeben waren. Das ist aber im Einzelfall auch schon rund 2 Jahre her in denen die VMs immer wieder auf neuere Server-Versionen umgezogen wurden, angefangen mit 1.0.2 bis 1.0.7 und dann auf den 2.0.0

Ein Update auf 2.0.1 steht demnächst dann aus, auch wegen der Sicherheitswarnung. Eventuell verbessert sich damit auch das Load-Problem, aber es wäre dennoch schön, wenn jemand Ideen hätte, worans liegen könnte.

Wenns hilft, hier einmal die komplette vmx-Datei einer VM auf System 3:

Genauso diesen System-Überblick dachte ich mir.

Für die maxPerformance einer VM sollte eigentlich immer ein CPU-Kern nebst ~1GB Ram für das Host-OS übrigbleiben und die restlichen Kerne können an VMs vergeben werden.
Von daher ist euer nur mit einem Xeon ( P4D-Reihe? etwa ) bestücktes System1 für mich schon gut belastet und dazu kommen noch mitwachsende v.HDD in allen VMs. Nur solange die VMs lediglich im Idle-Zustand laufen, bleibt die Last niedrig und die CPU-Leistung verteilt sich dann ausschließlich auf das Nadelöhr Datenträgerzugriff.

Die Voreinstellungen zu den VMs unterscheiden sich manchmal leider doch etwas in jeder Server-Version und sind daher auch aufgrund der Abhängigkeiten bei einzelnen Einstellungen nicht gerade übersichtlich. Zumal der VMserver je nach Version einige Einträge von sich aus manchmal doch in die VMX schreibt. Falls man diesen Mischmasch wirklich beseitigen wollte (obwohl nur sehr selten ein Veranlassung dazu bestehen könnte und nichtbenötigte/veraltet Einträge nicht beachtet werden), kommt man nicht umhin, alle nötigen Einträge in die VMX zu schreiben.

Um ein bisken experimentieren mit einzelnen Einstellungen wirst du nicht rumkommen. Einen guten und umfangreichen Einstieg in die Optimierungen für den Server2 findest du über die Forensuche zum Stichwort "swappiness". Die dort genannten Optimierungen schaden soweit bekannt dem Server in keinster Weise und verursachten bisher auch keine Datenverluste. Die VM laufen nur einfach runder und begrenzen den Datenträgerzugriff auf ein Minimum.

PS: Sind 256MB auch für ein Debian Lenny als VM nicht ein bisken wenig?

Moin,

swappiness werd ich mir mal anschauen.

Das unser System 1 ziemlich ausgelastet ist, ist uns bewusst und äh, bis vor ca. 1 Monat war es auch noch etwas schlimmer *g*

Die VMs die derzeit darauf laufen sind, wie man ja an den Load-Werten sieht, ziemlich unspektakulär, auch der Win2003 Server macht nicht mehr, als Sophos Updates zur Verfügung zu stellen und WSUS zu spielen.

Was vielleicht noch interessant ist: Wir hatten eine zeitlang nicht auf allen VMs die VMware-Tools installiert und als wir wegen der Warnmeldungen wegen zu hoher Load nachgeschaut haben, konnte man eine anwachsende Load auf allen Maschinen und demzufolge natürlich auch auf den Host feststellen, mit Ausnahme der VMs, die keine VMware-Tools hatten. Allerdings konnten wir nicht ganz nachstellen, dass es tatsächlich "nur" an den Tools hängt, da ein Stop der Tools auf den VMs nichts an der Last änderte. Erst ein Suspend oder Stoppen + Starten (so dass der Prozess zur VM gekillt wurde) hat die Last wieder reduziert.

Mittlerweile haben wir auf allen Maschinen die Tools drauf, weil wir auch annahmen, dass ein eventuell zu alter Stand Ursache sein könnte und auch weil wir ein Update von Build 11xxxx auf 122xxx durchgeführt haben.

Wenn du aber sagst, dass ein Kern für den Host über bleiben sollte, würde das bedeuten, man kann (oder sollte) bei 4 Kernen maximal 3 VMs laufen lassen? Das würde dann etwas schwer mit unserem Grundgedanken, dass für jeden Service eine eigene VM existieren sollte.

Daher reichen auch oftmals die 256 MB RAM, denn die VMs haben nicht viel zu tun. Zum Beispiel haben wir ein kleines internes Wiki laufen, dem reichen die 256 MB, auch ein ldapslave, der nicht viel zu tun hat, kommt mit 256 MB locker aus.

Was vielleicht auch nicht deutlich genug rauskam, es geht nicht um allgemein zu hohe Load, die ist in einem moderaten Bereich. Allerdings wächst sie beständig und das in einem Maß, dass nach dem Update auf VMware Server 2 Build 11xxxx im Dezember die Load von knapp unter 1 auf knapp unter 3 Anfang März gestiegen ist, wobei keine VMs dazu kamen oder sonstwie die Belastung angestiegen wäre.

Dieser Zuwachs liegt dabei komplett im user-Bereich der CPU, die Grundlast des Systems hat sich dabei nicht verändert. Ich würde eigentlich gerne der Einfachheit halber ein Bild aus Munin anhängen, auf dem man das wirklich schön sieht, aber aus irgendeinem Grund darf ich das wohl nicht...

Nunja, ich werde mir mal swappiness anschauen und dann nehmen wir demnächst auch noch das aktuelle Update vor, mal schauen, was sich damit so tut.

Hmm wenn ich das richtig sehe, hilft mir swappiness = 0 nur, wenn mein Host am swappen wäre oder?

Tut er aber nicht und tat er auch nie. Bringt es dann trotzdem was?

Die VMs selber swappen übrigens auch nicht.

Das unser System 1 ziemlich ausgelastet ist, ist uns bewusst und äh, bis vor ca. 1 Monat war es auch noch etwas schlimmer *g*

Ist das eigentlich ein richtiges Dualcore-System oder eine CPU mit HT?

Was vielleicht noch interessant ist: Wir hatten eine zeitlang nicht auf allen VMs die VMware-Tools installiert und als wir wegen der Warnmeldungen wegen zu hoher Load nachgeschaut haben, konnte man eine anwachsende Load auf allen Maschinen und demzufolge natürlich auch auf den Host feststellen, mit Ausnahme der VMs, die keine VMware-Tools hatten. Allerdings konnten wir nicht ganz nachstellen, dass es tatsächlich "nur" an den Tools hängt, da ein Stop der Tools auf den VMs nichts an der Last änderte. Erst ein Suspend oder Stoppen + Starten (so dass der Prozess zur VM gekillt wurde) hat die Last wieder reduziert.

Vielleicht Zeitabgleich mit dem Host oder Snapshots aktiv? Testweise vielleicht die VT-Fähigkeiten der CPU in der VM nutzen.

Wenn du aber sagst, dass ein Kern für den Host über bleiben sollte, würde das bedeuten, man kann (oder sollte) bei 4 Kernen maximal 3 VMs laufen lassen? Das würde dann etwas schwer mit unserem Grundgedanken, dass für jeden Service eine eigene VM existieren sollte.

Also VMware selber empfiehlt nicht mehr als 4 VMs pro Kern und sagt aber nicht weshalb, es sind aber auch mehr möglich. Meine Vermutung ist, daß der Verwaltungsoverhead sich ungünstig auf die Gesamt-Systemleistung auswirkt.

Was vielleicht auch nicht deutlich genug rauskam, es geht nicht um allgemein zu hohe Load, die ist in einem moderaten Bereich. Allerdings wächst sie beständig und das in einem Maß, dass nach dem Update auf VMware Server 2 Build 11xxxx im Dezember die Load von knapp unter 1 auf knapp unter 3 Anfang März gestiegen ist, wobei keine VMs dazu kamen oder sonstwie die Belastung angestiegen wäre.

VMware-Verwaltung könnte durch eine lange LAufzeit der VMs auch gestiegen sein, besonders bei mitwachsenden v.HDDs oder Snapshots.

Ich würde eigentlich gerne der Einfachheit halber ein Bild aus Munin anhängen, auf dem man das wirklich schön sieht, aber aus irgendeinem Grund darf ich das wohl nicht...

Das ist leider nix neues, poste einfach einen Link zu einem Freehoster.

Hmm wenn ich das richtig sehe, hilft mir swappiness = 0 nur, wenn mein Host am swappen wäre oder?

Tut er aber nicht und tat er auch nie. Bringt es dann trotzdem was?

Die VMs selber swappen übrigens auch nicht.

Versuch mal trotzdem die optimierten Einstellungen in den VMs. Der absolute Flaschenhals sind alle Datenträgerzugriffe egal ob vom Host oder durch eine VM an den Host per v.HDD delegiert.

Zitat:
Das unser System 1 ziemlich ausgelastet ist, ist uns bewusst und äh, bis vor ca. 1 Monat war es auch noch etwas schlimmer *g*
Ist das eigentlich ein richtiges Dualcore-System oder eine CPU mit HT?

Richtiger Dual-Core. Linux erkennt auch 2 Kerne.

Vielleicht Zeitabgleich mit dem Host oder Snapshots aktiv? Testweise vielleicht die VT-Fähigkeiten der CPU in der VM nutzen.

Zeitabgleich ist teilweise aktiv, im Regelfall nutzen wir aber ntp zum Zeitabgleich der VMs. VT-Fähigkeit der VM? Was muss ich mir darunter vorstellen bzw. was ist das?
Snapshots im Regelfall nicht, eventuell hat die ein oder andere VM einen, aber das kollidiert immer wieder mal mit dem Bedarf, die Platte zu vergrößern und wir machen regelmäßige Vollsicherungen unseres Systems und halten die Daten eh nicht in den VMs vor, sondern auf einem NAS. Also keine Snapshots.

Also VMware selber empfiehlt nicht mehr als 4 VMs pro Kern und sagt aber nicht weshalb, es sind aber auch mehr möglich. Meine Vermutung ist, daß der Verwaltungsoverhead sich ungünstig auf die Gesamt-Systemleistung auswirkt.

Das käme auf dem ersten System hin, dass es mehr als 4 VMs pro Kern sind, wenn einer frei bleiben soll, auf dem anderen aber zB schon nicht mehr, aber es haben ja beide das Phänomen, trotzdem behalte ich das mal im Hinterkopf.

Das ist leider nix neues, poste einfach einen Link zu einem Freehoster.

Ich schau was ich auftreiben kann...

Versuch mal trotzdem die optimierten Einstellungen in den VMs. Der absolute Flaschenhals sind alle Datenträgerzugriffe egal ob vom Host oder durch eine VM an den Host per v.HDD delegiert.

Du meinst das hier?

setz' mal als erstes in der /etc/sysctl.config deines Hosts den Parameter vm.swappiness=0
und dann füge in die *.vmx der VMs folgende Zeilen ein :
MemAllowAutoScaleDown="FALSE"
mainMem.useNamedFile = "FALSE"
mainMem.partialLazyRestore = "FALSE"
mainMem.partialLazySave = "FALSE"
und in die Config:
sched.mem.pshare.enable = "FALSE"

Hallo,

ja genau diese sind gemeint, damit bin ich meine Probleme losgeworden.

Vielleicht Zeitabgleich mit dem Host oder Snapshots aktiv? Testweise vielleicht die VT-Fähigkeiten der CPU in der VM nutzen.

Zeitabgleich ist teilweise aktiv, im Regelfall nutzen wir aber ntp zum Zeitabgleich der VMs. VT-Fähigkeit der VM? Was muss ich mir darunter vorstellen bzw. was ist das?

Dazu wären neben den von "e-e-e" schon genannten Einstellung noch zu nennen Eine kurze Erklärung der 3 Parameter findet sich im Thread Windows7 Beta1 unter Server2.... Wobei zum Parameter "mainMem.useNamedFile" noch zu sagen ist, daß dadurch Swap-File bzw Swap-Partition wesentlich größer als sonst werden. Eventuell braucht ein Linux-Host daher mehr Platz im /tmp-Verzeichnis. Bei Windows als Host ist das ja etwas unkritischer, zumindest solange die HDD ausreichend freien Platz vorhält. Ansonsten dürften sich die VMs eigentlich nur teilweise starten lassen.

Ich würde testweise mal nur einige VMs optimieren, dann sollten sich Unterschiede recht schnell zeigen. Du kannst auch mal exemplarisch den Inhalt einer vmware.log-Datei, zu finden im jeweiligen Unterordner der VM, posten und dann sehen wir auch gleich, woran es noch hängen könnte.

Ich muss schauen, wann ich ein Wartungsfenster bei uns für die Änderungen mache, eventuell heute nachmittag. Werde also vermutlich erst nächste Woche ein Feedback geben können, ob die Optimierungen was bringen.

Hier aber erst mal das Log einer VM auf System 1:

http://rafb.net/p/l80W8f97.html

Hallo,

mir sind im log 2 Sachen aufgefallen: 1. die Lizenz ist noch eine VMware Server 1.x - Lizenz (da ich noch den Server 1.08 benutze, kann ich nicht sagen, ob dort zwingend ein neues License-file benötigt wird), und 2. ist für die VMware Tools autoupgrade eingeschaltet, aber es scheint als ob es nicht richtig funktionieren würde (scheint der Versionsabgleich zu sein)

e-e-e hat geschrieben:Hallo,

mir sind im log 2 Sachen aufgefallen: 1. die Lizenz ist noch eine VMware Server 1.x - Lizenz (da ich noch den Server 1.08 benutze, kann ich nicht sagen, ob dort zwingend ein neues License-file benötigt wird), und 2. ist für die VMware Tools autoupgrade eingeschaltet, aber es scheint als ob es nicht richtig funktionieren würde (scheint der Versionsabgleich zu sein)

Also eigentlich sollten die Lizenzen von Version 1.xx auch unter Version 2.xx laufen, bei mir hat das jedoch nicht geklappt. Während der Inst hatte er die 1er Serien-Nummer noch angenommen, nach einem Reboot jedoch nicht mehr. Ich wollte daraufhin die neue eintragen, bekam nach dem Übernehmen aber immer eine Fehlermeldung. Eine Lösung brachte erst die Deinst mit Verneinen der Abfrage zum Erhalt der Serien-Nummer im Falle einer erneuten Inst, 2mal Rebooten und dann die Inst.

Wir haben nun letzten Freitag das System 1 auf den Server 2.0.1 geupdatet und auch alle VMware Tools der dort laufenden Maschinen. Zusätzlich wurde vm.swappiness=0 in die sysctl.conf des Hosts eingetragen.

Die weiteren Tuningmaßnahmen habe ich noch unterlassen, weil ich nicht wirklich nachvollziehen kann, was die machen bzw. den einen Schalter zu setzen hätte auf System 1 wohl auch nicht funktioniert, da monitor.virtual_exec = "hardware" nach dem was ich gelesen habe die speziellen Befehle für Virtualisierungsunterstützung der CPU nutzen will und System 1 hat keine.

Jedenfalls ist das Ergebnis bisher recht überzeugend. Die Systemlast ist deutlich gesunken, der User-Bereich derzeit auch noch minimal und als Bonus ist der iowait-Anteil während der Datensicherung deutlich gesunken.

Ich warte jetzt mal noch ab, wie es sich im Produktivbetrieb verhält, aber bisher würde ich sagen, das sieht alles sehr gut aus.

Bei der Lizenz hatten wir bisher keine Probleme, da wurde die alte immer mitgeschleift. Ich habe aber trotzdem bei der Installation am Freitag eine neue Lizenz passend zum 2.0.1 eingetragen. Es bleibt aber trotzdem bei dieser Meldung:
Apr 17 16:31:19.260: vmx| Licensecheck: Invalid license file.
Apr 17 16:31:19.262: vmx| LICENSE using: '/usr/lib/vmware/licenses/site/license.vs.1.0-00'
Die ich nicht ganz verstehe...

Ja stimmt, monitor.virtual_exec = "hardware" setzt VT in der CPU vorraus. Ansonsten funktionieren die anderen Einstellungen auch ohne VT. Sind halt alles Optimierungen um die IO-Last einer VM auf ein Minimum zu reduzieren. Die Erklärung zu allen Parametern findet sich auch auf Ulli's Seite http://sanbarrow.com
Ansonsten werden eigentlich alle Parameter irgendwo in diesem Forum erklärt. die Forensuche mit einem Parameter bringt jede Menge Treffer.

Den Fehler bei einem übernommenen Lizenz-Key verstehe ich auch nicht. Ist wohl doch mal wieder ein Posting bei VMware.com fällig.

Zu mainMem.useNamedFile = "false" habe ich mal ein bisschen recherchiert (bzw. eigentlich zu allen Tuningvorschlägen, aber dazu habe ich Fragen *g*).

Da wir einen Linux-Host haben, bzw. nur Linux-Hosts, würde dieser Schalter bedeuten, dass statt im Verzeichnis der VM eine .vmem Datei in Größe des RAMS der VM erzeugt wird, diese Datei nun in:
- /tmp erzeugt wird
- auf der Swap-Partition erzeugt wird

Da /tmp bei uns nicht gleich Swap ist, wäre das eine wichtige Frage.

Die Paritionierung sieht bei uns generell so aus:
1) /boot
2) Swap-Partition
3) / (Root-Verzeichnis)

Also nicht unbedingt ganz klassisch.

Edit: Ich sehe gerade auf sanbarrow, dass der Schalter auf einem Linux-Host eh nichts bringt: "This allocates all nominal guest-RAM completely into host-memory
Sorry - doesn't work on Linux"

Kann ich also vergessen?

Edit 2: sched.mem.pshare.enable <- steht in der gleichen Sektion und auf Linux-Host auch wirkungslos?

Hallo,

also SO radikal wie continuum dies beschrieben hat, scheint es nicht zu sein, da ein Linux nicht unter allen Umständen den Inhalt des vRAMs im pRAM behält. Ein Linux sagt halt immer: "ICH bin der Verwalter aller Resourcen und KEIN Programm schreibt mir da was vor!" Das hat Vorteile, aber manchmal, wie hier, eben auch Nachteile.

Ich würde den Parameter trotzdem mit reinnehmen. Probleme sind bisher nicht bekannt geworden, er stört also nicht und vielleicht bewirkt er ja bei einem neueren Kernel doch etwas für VMware positives.

Den? Welchen der beiden denn oder beide?

Und wohin wird die .vmem Datei denn nun geschoben, nach /tmp oder in den Swap? Bei /tmp gewinnen wir leider gar nichts, dann hab ich sie lieber im VMware-Ordner. Bei Swap bin ich damit auch nicht glücklich, denn der ist teils deutlich kleiner als physikalischer RAM da ist und damit wäre der schneller voll als der eigentliche RAM.

Oder wird der RAM durch einen der beiden Schalter komplett im Host-RAM gehalten, ohne .vmem-Datei? Das wäre sinnvoll und ein durchaus wünschenswertes Verhalten.

Edit:
mainMem.partialLazyRestore = "FALSE"
mainMem.partialLazySave = "FALSE"

Müssen die in die vmx-Dateien oder kann ich das auch global einstellen? Snapshots sind bei wachsenden Platten eh blöd und verhindern späteres Vergrößern oder Shrinken, daher braucht da auch nichts im Hintergrund zu passieren.

Hallo,

also Du kannst diese beiden Zeilen in die *.vmx für eine spezielle VM eintragen, oder in die config als globale Einstellungen für alle VMs schreiben. Durch wird nicht die *.mem-Datei woanders angelegt, sondern im Fall von Linux, falls RAM dennoch ausgelagert wird, dies mit auf die swap-Partition geschied. Allerdings muss ich sagen, dass bei mir die swap-Partition nur mit 150 KB belegt ist, also kommt es de facto nicht zum swappen.

Hat leider nichts gebracht bisher...

Das System hat weiterhin kontinuierlich wachsende Load. Allerdings haben wir nicht alle Tuningmaßnahmen an dem System getestet, deswegen letzten Freitag ein anderes, dass seitens der CPU VT unterstützt ebenfalls geupdatet.

Mal sehen, wie sich das entwickelt. Ich vermute aber, das läuft ebenfalls in Probleme, weil es die CPU-Taktung drosselt, wenn es nichts zu tun hat. Da wir aber, gerade im Sommer, immer wieder in ein Hitzeproblem im Serverraum laufen, ist es derzeit keine gute Idee, die CPU durchrödeln zu lassen.

Wann sich das mit einer neuen, besseren Klimaanlage erschlagen lässt, ist nicht sicher, da unser Vermieter überlegt im kompletten Werksgelände die Klimaanlage dahingehend umzustellen, dass nicht mehr etagenweise, sondern raumweise eingestellt werden kann. Dann müssten wir da nicht selber was reinbauen lassen. Die Frage ist halt nur, wie schnell das geht.

Aber bis dahin würde ich die CPUs nur sehr ungern auf Dauervollast setzen.

Noch andere Ideen?

Ich hab da auch noch was gelesen, den Host von 1000 MHz auf 100 MHz umzustellen. Was muss ich mir darunter vorstellen und wie muss ich dafür vorgehen? Grobe Anleitung dazu reicht mir

Mal sehen, wie sich das entwickelt. Ich vermute aber, das läuft ebenfalls in Probleme, weil es die CPU-Taktung drosselt, wenn es nichts zu tun hat. Da wir aber, gerade im Sommer, immer wieder in ein Hitzeproblem im Serverraum laufen, ist es derzeit keine gute Idee, die CPU durchrödeln zu lassen.

Die Energiespareinstellungen auf Host und Gast zu aktivieren, ist ungüstig in meinen Augen. Worst-Case wäre dann, wenn der Host die CPU-Speed drosselt und die VM meint auf Volllast zu sein.
Ich lasse daher meine VMs immer nur mit deaktivem Energiesparkram laufen. Meine einzigste aktive Einstellung in einer VM betrifft nur den Monitor. Der wird nach einer gewissen Zeit abgeschaltet und das System gesperrt.

Ich hab da auch noch was gelesen, den Host von 1000 MHz auf 100 MHz umzustellen.

Die Einstellung die du meinst, läßt sich per VI-Client aber nur auf dem ESX/ESXi einstellen. Der VI-Client aus dem Server2.00 (bei v2.01 wird er ja nicht mitgeliefert) bietet an der Stelle nur die Einstellung die CPU-Affinität. Damit kannst du eine VM praktisch an einen bestimmten CPU-Kern binden. Ist eigentlich nur auf einem Core2Quad oder Xeon-Core2Quad und deren FSB-Flaschenhals interessant.

Ich meinte damit auch nur die Optionen auf dem Host.

Bei den Gastsystemen habe ich zumindest nicht bewusst solche Einstellungen vorgenommen und das BIOs von VMware bietet da auch keine Möglichkeiten, zumindest habe ich keine gefunden.

In den Windows-VMs, die im Produktivbetrieb bei uns aber nur sehr selten zu finden sind, werde ich das aber mal checken, ob da was eingestellt ist und werde da auch drauf achten, dass diese nicht versuchen, Energie zu sparen.

Interessant ist jedenfalls, dass auf dem System mit VT und dem neuen Server die Load an sich gesunken ist (gegenüber Server 1.0.7) und das Anwachsen der Load im User-Bereich bisher nicht zu sehen ist, obwohl dort einige VMs auch dauerhaft laufen, allerdings nicht alle mit VMware-Tools. Eigentlich sogar quasi keine mit aktuellen VMware-Tools wenn überhaupt welchen.

Damit wären die Tools irgendwie nicht so förderlich, wie sie sein sollten... Wenn sich denn meine Beobachtung fortsetzen sollte.

Das Problem besteht leider immer noch...

Wir testen nun mit open-vm-tools, aber auch da sieht es im Moment so aus, als würde die Load langsam steigen...

Da die meisten unserer VMs reine Konsolenmaschinen sind (Debian netinst lennys), stellt sich die Frage, wofür braucht man die Tools da?

Suspenden geht ohne, Load verbessert sich definitiv nicht. Was wären denn sonst die Vorteile der Tools oder was geht nicht mehr, wenn keine Tools installiert wären? Maus ist eh keine in den VMs, Datentransfer findet über eh übers Netz statt, also wo wäre der Nutzen der Tools in dem Fall?

Falls das hier außer mir noch jemand verfolgt *gg*

Wir haben wohl die Lösung gefunden.

Die VMs kommen ursprünglich vom 1er Server und wurden umgezogen.

Nachdem wir auf einem Server alle VMs neu erstellt und die vmdk's eingebunden haben, sieht die Load seit 2 Tagen konstant aus und ist damit schon deutlich niedriger als bei früheren Tests und! sie steigt nicht an.

Damit ist wohl irgendwas in der vmx schief gewesen, was man nicht unbedingt auf Anhieb findet und ich rate daher jedem, wenn er von 1 auf 2 upgradet, die VMs neu anlegen und die vmdks dann einbinden.