Hohe Load auf Host

[Dayworker]

Ja ich.

Wenn du jetzt mal eine aktuelle VMX veröffentlichen würdest...

[shecki]

Gerne doch:

Code: Alles auswählen

#!/usr/bin/vmware
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "7"
floppy0.present = "FALSE"
mks.enable3d = "TRUE"
pciBridge0.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "TRUE"
nvram = "svn.nvram"
virtualHW.productCompatibility = "hosted"
ft.secondary0.enabled = "TRUE"
tools.upgrade.policy = "useGlobal"
powerType.powerOff = "soft"
powerType.powerOn = "hard"
powerType.suspend = "hard"
powerType.reset = "soft"

displayName = "vmname"
extendedConfigFile = "vmname.vmxf"

memsize = "512"
ide1:0.present = "TRUE"
ide1:0.fileName = "/dev/hda"
ide1:0.deviceType = "atapi-cdrom"
ide1:0.allowGuestConnectionControl = "FALSE"
ethernet0.present = "TRUE"
ethernet0.allowGuestConnectionControl = "FALSE"
ethernet0.features = "1"
ethernet0.wakeOnPcktRcv = "FALSE"
ethernet0.networkName = "Bridged"
ethernet0.addressType = "generated"
guestOS = "linux"
uuid.location = "56 4d ef 8d ff 03 7f 44-c2 48 c2 c5 e0 b0 62 4d"
uuid.bios = "56 4d ef 8d ff 03 7f 44-c2 48 c2 c5 e0 b0 62 4d"
vc.uuid = "52 cd 04 2b d5 e5 b4 8a-02 ef 41 12 b0 82 f6 92"

scsi0.present = "TRUE"
scsi0.sharedBus = "none"
scsi0.virtualDev = "lsilogic"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "vmname.vmdk"
scsi0:0.writeThrough = "TRUE"
ethernet1.present = "TRUE"
ethernet1.allowGuestConnectionControl = "FALSE"
ethernet1.features = "1"
ethernet1.wakeOnPcktRcv = "FALSE"
ethernet1.networkName = "Bridged2"
ethernet1.addressType = "generated"

ethernet0.generatedAddress = "00:0c:29:b0:62:4d"
ethernet1.generatedAddress = "00:0c:29:b0:62:57"
tools.syncTime = "FALSE"
scsi0:0.redo = ""
vmotion.checkpointFBSize = "16777216"
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
scsi0.pciSlotNumber = "16"
ethernet0.pciSlotNumber = "32"
ethernet1.pciSlotNumber = "33"
vmci0.pciSlotNumber = "34"
ethernet0.generatedAddressOffset = "0"
ethernet1.generatedAddressOffset = "10"
vmci0.id = "-525311411"


[Dayworker]

Ist die gepostete VMX vom April'09 deine alte?

[shecki]

Es ist eine alte, es dürften aber nicht die korrespondierenden zum gleichen System sein, wenn du das wissen willst.

Wenn du von jeweils der gleichen Maschine alt + neu willst, musst du noch bis nächste Woche warten, dann werde ich eine der Maschinen entsprechend neu machen und beide vmx-files hier posten.

bzw. in dem Fall hast du sogar Glück, hier die "alte" vmx des gleichen Systems::

Code: Alles auswählen

#!/usr/bin/vmware
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "7"
scsi0.present = "TRUE"
memsize = "512"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "vmname.vmdk"
ide1:0.present = "TRUE"
ide1:0.fileName = "/dev/hda"
ide1:0.deviceType = "atapi-cdrom"
floppy0.fileName = "/dev/fd0"
Ethernet0.present = "TRUE"
displayName = "vmname"
guestOS = "other26xlinux"
priority.grabbed = "normal"
priority.ungrabbed = "normal"

scsi0:0.redo = ""
ethernet0.addressType = "generated"
uuid.location = "56 4d cd 8a 21 5c 86 1a-51 17 9f 6b f6 2f 3d f8"
uuid.bios = "56 4d 53 78 d6 3f 1d 65-26 07 19 75 48 58 ca 9f"
ide1:0.autodetect = "FALSE"
ethernet0.generatedAddress = "00:0c:29:58:ca:9f"
ethernet0.generatedAddressOffset = "0"

ide1:0.startConnected = "FALSE"
floppy0.startConnected = "FALSE"
Ethernet1.present = "TRUE"
Ethernet1.connectionType = "custom"
Ethernet1.vnet = "/dev/vmnet2"

ethernet1.addressType = "generated"
ethernet1.generatedAddress = "00:0c:29:58:ca:a9"
ethernet1.generatedAddressOffset = "10"

tools.syncTime = "FALSE"

autostart = "none"

workingDir = "."

checkpoint.vmState = ""

scsi0:1.present = "FALSE"
scsi0:1.fileName = "Other Linux 2.6.x kernel.vmdk"

scsi0:1.redo = ""

extendedConfigFile = "vmname.vmxf"
virtualHW.productCompatibility = "hosted"
tools.upgrade.policy = "manual"

vmotion.checkpointFBSize = "16777216"
tools.remindInstall = "FALSE"

ethernet0.networkName = "Bridged"
ethernet0.features = "1"
debugStub.linuxOffsets = "0x0,0xffffffff,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0"

mks.enable3d = "TRUE"
pciBridge0.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge5.present = "TRUE"
pciBridge6.present = "TRUE"
pciBridge7.present = "TRUE"
vmci0.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.pciSlotNumber = "21"
pciBridge4.functions = "8"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.pciSlotNumber = "22"
pciBridge5.functions = "8"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.pciSlotNumber = "23"
pciBridge6.functions = "8"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.pciSlotNumber = "24"
pciBridge7.functions = "8"

pciBridge0.pciSlotNumber = "17"
scsi0.pciSlotNumber = "16"
ethernet0.pciSlotNumber = "32"
ethernet1.pciSlotNumber = "33"
vmci0.pciSlotNumber = "34"
vmci0.id = "1213778591"

ide1:0.allowGuestConnectionControl = "FALSE"


[Dayworker]

Jep, der Vergleich wäre wirklich mal interessant. Kann mir eigentlich nicht vorstellen, daß es da große Unterschiede geben sollte. Allerdings kann man die VMX zweier Versionen meist nicht richtig vergleichen. Einige Einträge sind bei manchen Server-Versionen zum Standart geworden und werden dann anscheinend nicht mehr eingetragen. Von daher ist manchmal weniger doch mehr.

[shecki]

Also die beiden zuletzt geposteten entsprechen:
- die von 1.0.x hoch gezogenene VM
- die mit den vmdk's der ersten erstellte neue VM

Also ein zusammen gehörendes Paar. Die vmx aus den 1.0.x Zeiten habe ich natürlich leider nicht mehr.

[Dayworker]

Ich hab mir mal alle Unterschiede rausgesucht und hoffe, ich hab nichts übersehen:
neu ZU alt
--- ZU nvram = "svn.nvram"
debugStub.linuxOffsets = "0x0,0xffffffff,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0" ZU ---
guestOS = "linux" ZU guestOS = "other26xlinux"
Ethernet1.connectionType = "custom" ZU ethernet1.networkName = "Bridged2"
Ethernet1.vnet = "/dev/vmnet2" ZU ---
vmci0.id = "1213778591" ZU vmci0.id = "-525311411"

Meine Vermutung liegt in der GuestOS-Version "linux" und "other26xlinux" neben der unterschiedlichen vmci0.id, wo ich nicht weiß wofür das gebraucht wird, sowie der Ethernet-Geschichte mit "Costum" + "/dev/vmnet2" und "Bridged2". Irgendwo dabei wird er wohl vermutlich seinen Hickup haben.
Ansonsten sollte man generell bei Umzug der VM von Win- auf Linux-Host die Gerätezuordnung überprüfen und die Konventionen des Host-OS einhalten ("Bridged2" kenn ich bisher nur bei Win-Hosts und "/dev/..." nur unter Linux-Hosts).

[shecki]

Dann verrate ich dir mal, dass wir nicht einen Windows Host haben sondern nur Linuxe

Und die VM an sich ist auf dem gleichen Server, also nix umgezogen, sondern nur vmdk's in in eine neu erstellte eingebunden.

Aber das mit den Ethernet-Sachen klingt plausibel, zumal in der Konsole Bridged2 auch vorher schon stand, aber wohl nicht sauber in die vmx übertragen wurde oder so ähnlich.

[Dayworker]

Jep, allerdings sollte das bei reinen Linux-VTs nicht auftreten. Könnte allerdings sein, daß nur bei "Costum" das VMnetX angegeben werden muß und ansonsten das "Bridged2" ausreicht...

[shecki]

Tja, auch wenn wir angefangen haben, nach den viel versprechenden ersten Ergebnissen, unsere VMs neu anzulegen, stellen wir trotzdem eine steigende Load fest mittlerweile. Deutlich langsamer als vorher, aber sie ist da.

Was ich auch gesehen habe (und was mich ein bisschen erschreckt hat), wir sind noch auf 2.0.0., dabei war ich mir sehr sicher, dass wir hier schon geupdatet hatten...

Aber da es nicht nur uns so geht:
http://communities.vmware.com/thread/224183

muss man wohl auf 2.0.2 hoffen oder immer mal wieder das System durchstarten (also suspend/stop und start, da Prozess weg sein muss).

Wobei vielleicht einer der Cracks sagen könnte, ob es mit 2.0.1 gegenüber 2.0.0 Besserung geben könnte und wenn ja, warum, weil in den Release-Notes steht nichts, was in diese Richtung weisen würde. Werden wir aber wohl trotzdem testen, sobald möglich. Weil interessanter Weise ist unser Testserver bereits 2.0.1 und hat nicht die steigende Load im User-Bereich. Allerdings laufen darauf auch nur wenige Maschinen dauerhaft, der Rest wird jeden Abend suspended (nachdem die Entwickler über 20 Maschinen oben hatte, weil sie zu faul waren, die zu stoppen, mussten wir eben was tun ). Genauer gesagt, laufen nur 2 Maschinen dauerhaft durch, insofern ist das vermutlich kein adäquater Vergleich.

[shecki]

Mal wieder ein neuer Stand:

Die Load steigt immer noch, auch nach dem UPdate zu 2.0.1.

Da nun 2.0.2 draußen ist, testen wir das derzeit, allerdings auf einem 32 bit Server, die produktiven sind leider alle 64 bit, insofern weiß ich nicht, ob der Test nicht ein Muster ohne Wert ist...

Jemand Meinungen dazu?

Aber immerhin ist da seit vorgestern keine steigende Load zu verzeichnen, aber 2 Tage sind auch noch nicht wirklich aussagekräftig. Zusätzliches Problem ist, da laufen nur 4 VMs und laufen ist übertrieben, eigentlich idlen die nur rum. Muss da mal Feuer machen *g*

[Dayworker]

Ich bin immer noch erstaunt über deine Leidensfähigkeit. Was war eigentlich nochmal der Grund, auf den VMserver2 umzusteigen...ich hab's entweder vergessen oder überlesen

[shecki]

Naja es hieß mal oder wir haben angenommen oder sowas in die Richtung, dass mit der neuen 2er Version die 1er nicht mehr weiter entwickelt wird...

Und damit wäre der Umstieg früher oder später Pflicht...

Naja, zurück migrieren wollen wir eigentlich nicht, zumal wir dann jede VM von Hardware 7 wieder auf Hardware 4 schubsen müssten und das könnte ggf. umständlich bis problematisch werden.

Naja, ich denke mal, wir werden zum Wochenende hin die neue Version 2.0.2 aufspielen und mal schauen, wie es sich damit verhält. Ansonsten hoffe ich, dass VMware auf die sich mittlerweile doch häufenden Klagen von Leidensgenossen bemüßigt sieht, was zu tun (WEHE es lacht wer ).

Immerhin hab ich wohl auch auf der 32 bit Testmaschine die steigende Load erzeugen können, einfach indem 4 Maschinen darauf laufen, aber mit denen kann ich nun viel mehr testen und viel mehr tolle Parameter verändern und so

Blöd ist halt, man muss mindestens mal 3 Tage warten, um zu sehen, ob etwas anschlägt oder nicht...

[Dayworker]

Sehr interessant finde ich übrigens deinen Link vom 02.10.09, alle Poster scheinen RHEL bzw CentOS auf dem Host zu fahren. Kernel 2.6.26 wird auch hin und wieder in den Verlinkungen erwähnt.

[shecki]

Ja ich mag dich auch ...

Wir setzen übrigens Debian Lenny ein, nur falls ich das noch nicht gesagt habe

Etwas ist mir an dem Server, den ich zum testen missbrauche heute aufgefallen:
Gestern habe ich dort, nachdem klar war, dass er auch steigende Load hat, auf ALLEN VMs dort die VMware Tools deinstalliert.

Ob das für die Load einen Erfolg bringt, weiß ich noch nicht, aber etwas sehe ich schon:
Die "Available Entropy" in Munin ist von ca. 200 auf 3000-3500 hoch und das seit dem Zeitpunkt, an dem ich die Tools entfernt habe...

Könnte es da irgendwie zu Problemen kommen, dass Prozesse eben Entropie brauchen (ist ja für zufallsbasierte Sachen wichtig, sprich Verschlüsselungen) und wenn ich weiter schaue, heißt hohe Load, insbesondere iowait, eine hohe verfügbare Entropie, was umgekehrt gedacht bedeuten könnte, wenn mehr Entropie gebraucht wird, steigt eben die Load. Was jetzt nicht unbedingt technisch korrekt ist, aber anhand der Graphen sich belegen ließe, wenn ich mir das so anschaue...

Vielleicht kann ja jemand mit mehr Hintergrundverständnis mit den Hinweisen was anfangen

[Dayworker]

Das Debian Lenny erwähntest du schon vor einer Ewigkeit im Eröffnungsposting.
Ich hab mir das grad nochmal zu Gemüte geführt und auf jedem Host laufen immer mehr VMs als CPU-Kerne vorhanden sind. Allein dadurch dürfte sich die Last in den VMs hochschaukeln, besonders da alle VMs über mitwachsende v.HDDs verfügen.
Welche Abfragehäufigkeit hast du eigentlich in Munin eingestellt? Wenn du vom Host aus deine Gäste überwachst, dauert die Aktualisierung und je nach Anzahl der VMs auch mal etwas länger. Gleichzeitig steigt dabei auch die Last in der VM durch die Abfragen.

Die VMware-Tools sind in meinen Augen nur paravirtualisierte Treiber zu bestimmter HW und sorgen für deren direkte Kommunikation ohne den sonst nötigen Eingriff des Hypervisors. Als Nebeneffekt lassen sich darüber die Uhrzeit synchronisieren, die v.HDD schrinken und die VM remote verwalten.

[shecki]

Du meinst also, wenn man die Platten komplett vom Start weg anlegen würde, könnte das das Problem verringern oder erschlagen?

Könnte man zumindest mal probieren, für die produktiven Systeme, die Testsysteme nicht, die werden aber eh jeden Abend suspended, außer in Ausnahmen.

Die Tools sind ein gutes Stichwort. Bei reinen Shell-VMs, also ohne Grafische Oberfläche, machen sie vermutlich noch weniger Sinn? Zeitsync machen wir eh aus den VMs per ntp, ist einfach zuverlässiger, als da VMware zu vertrauen, ich müsste aber noch mal schauen, ob das mit dem Neumachen der VMs nicht wieder drin ist, vermutlich schon...

Ich meine auch, wir hätte mal Probleme mit Suspend bei VMs ohne Tools gehabt, kannst du das bestätigen oder sollte das unabhängig von den Tools gehen? Ein "richtiger" Shutdown, sprich dem OS wird ein Shutdown befohlen, nicht nur ein Power off, dürfte aber nur mit Tools gehen oder?

Das waren halt bei uns die Gründe, die Tools zu nehmen und bei den wenigen Windows VMs halt auch die Treiber etc. aber die fallen weniger ins Gewicht denke ich.

[Dayworker]

Wenn eine v.HDD als Sparse angelegt ist, sucht sie sich ja erst ihren Platz, wenn Zugriffe erforderlich sind. Jedes OS führt aber im Hintergrund noch weitere Prozesse aus, die natürlich ihre Aktivitäten auch irgendwo zu Protokoll bringen wollen. Wenn das dann mehrere VMs betrifft, wäre ein Hochschaukeln denkbar.

Die VM-Tools machen in meinen Augen auch bei Shell-VMs außer vielleicht DOS einen Sinn. Die VMs lassen sich auch vom Host oder sonstwo unbürokratisch (ohne Web-Browser oder VI-Client) und schnell (per CMD oder Ba$h) über VMware-Mittel administrieren und auch diese VMs haben eine Text-Anzeige, die sonst der Hypervisor wieder Zeichen für Zeichen abfangen und umsetzen müßte. Die Zeitsyncronisation ist dabei in meinen Augen nur ein Nebenprodukt, denn über diese VM-Kanäle wurde auch die beim Server1 noch mögliche Integration in ein VC administriert.

Ein richtiger Shutdown geht auch ohne Tools, es kommt nur drauf an, was du für die betreffende VM in den Startup/Shutdown-Einstellungen eingetragen hast und ob die VM auf WOL lauschen soll.
Ich persönlich bevorzuge den Shutdown auch im USV-Einsatz und nutze nur in Ausnahmefällen (Updates auf dem Host-OS einspielen) den Suspend, da er bei großen Arbeitsspeicherzuweisungen durch das fehlende Niederschreiben des RAM-Inhaltes schneller ist und dadurch hoffentlich auch sicherer für die Daten sein sollte.

[shecki]

Also zunächst das Positive:
Auf dem Testsystem ist ohne die Tools keine steigende Load mehr erkennbar und da dort ein Nagios-System ständig Abfragen macht, hat es auch ständig was zu tun und hatte letzte Woche zwar nur eine kleine Steigerung, aber sie war da. Übers WE fehlt diese Steigerung.

Dann jetzt noch mal zu den Vor- und Nachteilen ohne Tools.
Auf unseren paar Windows-Servern sollten sie denke ich drauf bleiben, allein schon wegen der besseren Treiberunterstützung.

Aber auf den Linux-Kisten würde ich gerne über die Nachteile nochmal genauer reden. Da wir diese eh komplett nur über ssh, sprich putty ansprechen, brauchen wir da nichts von VMware, das haben wir bisher nicht genutzt und werdens daher auch kaum vermissen

Start/Stop/Suspend wären halt die Knackpunkte, genau wegen USV, wie du sagst
Das Suspenden hat hier mit den Tools gut funktioniert und wir konnten die VMs danach auch wieder sauber hochfahren. Wenn das auch ohne Tools geht, brauchen wir sie eigentlich nicht.

Gibt dann zwar immer das Problem mit der Zeit, aber das gleicht ntp dann ja aus.

Wenn also beim Suspenden der VMs nichts kaputt geht bzw. das an sich funktioniert, können die Tools von 90% unserer Maschinen wieder runter

[Dayworker]

Suspenden kannst du eigentlich auf zweierlei Art. Entweder über Suspend von VMware oder das normale Suspend vom Gast-OS.
Über die nicht steigende Last allein übers WE muß ich nochmal nachdenken.

[edit 20:15]
Wenn am WE die Last nicht ansteigt, bleibt dort ja nur die fehlende Benutzerinteraktion übrig. SSH verbraucht für den verschlüsselten Zugang auch immer etwas Leistung, dazu kommt die Console selbst und mit jedem neuen SSH-Zugang wird eigentlich auch immer eine neue Console geöffnet. Wenn sich dann am Freitag alle ausloggen, werden auch alle offenen Sessions geschlossen und dadurch der Arbeitsspeicher entmüllt. Darüber könnte ich mir die Lastwechsel von Woche zu WE erklären.
Oder ich bin damit auch komplett auf dem Holzweg.

[shecki]

Bist du *gg*

Der Testserver kriegt seine Last eigentlich nur durch ein dort laufendes Nagios und eben insgesamt 5 laufende VMs. Keine Userinteraktion. Daher ist auch Woche/WE nicht relevant, ich hab halt nur über die letzte Woche mit Tools getestet, Freitag deinstalliert und gestern und auch heute eben keine steigende Load festgestellt, im Gegensatz zu letzter Woche, als diese vorhanden war.

Suspend wird über VMware durchgeführt, bzw. über die Konsole des Hosts, genauer mittels vmrum, falls halt Strom ausfällt und die USV ran muss. Das muss ohne Tools gehen, dann sind wir schon mal nen gutes Stück glücklicher

[shecki]

Sooo nach den Ergebnissen auf dem Testserver habe ich einen der produktiven Server auch umgestellt:

2.0.2 drauf und die Tools von allen Linux-Maschinen runter.

Ergebnis nach 2,5 Wochen: Die Load steigt erheblich langsamer an, weil nur noch die beiden Windows-Kisten mit ihren Tools rumfuhrwerken. Normal hätte man hier in Munin wohl schon Werte um 50% User-Load, derzeit sind wir bei 20%, gemessen an 200% für 2 CPUs.

Parallel sieht man auch hier den Anstieg der Available Entropy und auch eine leichte Zunahme von iowait bei der CPU-Auslastung (von ca. 10% auf 12%).

Montag habe ich dann einen weiteren Server umgestellt, da erwarte ich mir die gleichen Ergebnisse und auch die restlichen Server werden nach und nach folgen. Allerdings ist hier interessant, dass der Anstieg der Available Entropy fehlt, aber iowait steigt auch hier leicht an (von 6% auf 8%, hier auf 400% gesehen).

Der Unterschied der Systeme liegt wohl darin, dass das letzte System Virtualisierung unterstützt chipsatzmäßig, die anderen beiden wohl eher nicht (etwas zu alt dafür).

Die Festplatten sind übrigens weiterhin anwachsend, aber ich glaube nicht, dass die noch viel wachsen, weil dazu müsste sich auch die Festplattenauslastung erhöhen, was sie nicht tut. Sollte also mittlerweile ziemlich konstant sein, was die Größe angeht hier.

Nur mal so für den aktuellen Stand

[Dayworker]

Schönes Update.
Ich bewundere immer mehr deine Geduld und hätte den VMserver2 schon längst zum VMserver1.10 upgraded.
Aber zumindest bist du nicht alleine mit dem Problem, im VMTN finden sich auch viele Postings dazu. Ich tippe immer mehr auf ein Problem der VMware-Tools mit den neueren Kernel-Versionen und den dort erfolgten Umstellungen.

[shecki]

Wir haben halt alle VMs auf HW7, daher ist zurück so ne Sache...

Aktuell überlegen wir eher an VirtualBox, vor allem weil man dort schon VMs im laufenden Betrieb beamen kann und dann einen Server dazu hätten wir genug Reserven, um die Server schön frei zu haben und was dran machen zu können.

Weil ohne die Tools haben wir nun das Problem, das iowait ansteigt und beim Kopieren einer VM hats den Server extrem in die Knie gedrückt, sprich alle VMs Timeout und bei den Webanwendungen ist man rausgeflogen. Liegt auch eindeutig dran, dass die Tools weg sind, wie ja schon beim letzten Mal gesagt.

[Dayworker]

Wie schon mal geschrieben, wäre die Rückkehr zur alten v.HW-Version 4 kein Problem und läßt sich über ein oder zwei manuelle Eingriffe pro VM erledigen. Ich glaube immer mehr, daß Debian Lenny kein guter Boden für den VMserver2 ist. Allerdings hat selbst Ubuntu-9.10 (wenn der VMserver2 sich überhaupt ohne Any-Any-Patch installieren läßt) seine Probleme mit 2-Kern-VMs, zumindest finden sich dazu entsprechende Hinweise sowohl bei VMware als auch bei Virtualbox. Mit CentOS5.4 ist momentan auch kein richtiger Blumentopf zu gewinnen, je nach Kernel-Version gibt es dort auch manchmal lösbare (Lib aus CentOS5.3 kopieren) und unlösbare Probleme.