Hallo zusammen,
wie hier sicher alle wissen betreibe ich ja seit geraumer Zeit mehrere
Xen-Cluster (http://shell.uugrn.org/~mh/UUGRN-Real_Virtuality.pdf).
Mittlerweile sind es 22 dom0s die von mir (mit-)verwaltet werden und es gibt
sogar Leute die mein Setup nutzen und es selbst verwalten.
Da KVM in letzter Zeit sehr viel Aufmerksamkeit erregt hatte und
Xen-dom0-Support noch immer nicht im vanilla Linux-Kernel vorzufinden ist
habe ich mir mal den aktuellen Entwicklungs-Stand von KVM in Hinblick auf
mein Xen-Setup angeschaut. Der konkrete Auftrag war dann sogar noch dass ich
die Tauglichkeit fuer Windows 2008 testen sollte - was man nicht alles tut...
Fuer meine KVM-Tests habe ich Debian squeeze verwendet mit Kernel 2.6.32 und
qemu-kvm 0.11.
Ich habe zwei Stueck Hardware (Pentium D 3GHz) fuer die Tests gehabt auf welchen
ich zuerst mein Standard-Setup (Xen-Cluster) mit Debian lenny eingerichtet
habe und Performance-Tests durchgefuehrt habe. Hier habe ich allerdings nur
Linux-domUs (Gaeste) getestet, da die Unterstuetzung von HVM bei Debian lenny
nicht so toll ist (z.B. keine Live-Migration moeglich). Dadurch konnte ich
direkte Aussagen zwischen Xen und KVM auf derselben Hardware treffen!
Wenn man einen KVM-Gast betreibt sollte man aufjedenfall die virtio-Treiber
fuer Festplatten und Netzwerkkarten in den Gaesten verwenden, ansonsten ist die
Performance natuerlich sehr schlecht und quasi gleichlangsam wie mit dem
reinen qemu (ohne Kernel-Modul).
Ich habe kurze Tests mit aktiviertem KSM (Kernel Samepage Merging)
durchgefuehrt, allerdings habe ich sehr schnell bemerkt dass dies die
Performance erheblich bremst. Bestimmt wird es nett sein wenn man ein oder
zwei mal am Tag den ksmd den Speicher "komprimieren" laesst, fuer meine Tests
habe ich das aber nicht verwendet.
Sehr eigenartig ist die Verwendung von Linux als Hypervisor. Wenn jeder Gast
einfach nur EIN Prozess ist und genauso Swap nutzen kann wie jeder andere
Prozess auch. Da muss man doch sehr aufpassen dass man in keine OOM-Situation
kommt, sonst kann es sein dass der "oom-killer" einen Gast "beendet" weil
dieser ja viel RAM belegt!
Ein direktes Resultat von diesem Speichermanagement ist, dass man
Speicher "over-commitment" machen kann und dabei nichteinmal gewarnt wird!
Die Gaeste allokieren den Speicher auch erst, wenn sie diesen benoetigen.
Bei Xen gibt man beim Start einer domU den maximalen RAM an welche eine domU
im Betrieb belegen darf, dieser RAM muss beim Start (oder bei einer
Live-Migration auf dem Zielsystem) verfuegbar sein! Ein
Speicher "over-commitment" ist bei Xen (momentan) nicht moeglich.
Man kann sich nun darueber streiten ob das gut oder schlecht ist. Persoenlich
finde ich den Ansatz von Xen stabiler aber halt auch unflexibler.
Zur Verwaltung der KVM-Gaeste habe ich libvirt verwendet. Es gibt ein
grafisches Frontend, virt-manager, aber das ist aus meiner Sicht maximal
zum "Kucken" und "Schieben" tauglich. Beim Erstellen eines neuen Gastes mit
virt-manager ist z.B. per Default eine virtuelle Soundkarte dabei und die
Festplatten werden MIT caching angesprochen.
Mir war es wichtig die Gaeste unter KVM moeglichst mit denselben Bedingungen wie
unter Xen zu betreiben.
Ich habe es dann auch geschafft mit einem KVM-Gast denselben Durchsatz fuer
Festplatte und Netzwerk zu bekommen wie bei einer Xen domU. Allerdings hat
KVM eine hoehere CPU-Last auf die Hardware dabei erzeugt als bei Xen.
Im Skalierungstest ist Xen bisher ungeschlagen. Bei Xen skaliert der Durchsatz
quasi proportional zur Anzahl der domUs die Durchsatz machen. (Mein bisher
groesster Test waren 64 laufende domUs auf einer, nicht dieser, Hardware.). Bei
KVM habe ich schon bei ca. 8 gleichzeitig laufenden Gaesten einen sehr starken
Einbruch bemerkt (OK, die darunter liegende Hardware ist schon etwas aelter).
Auch die CPU-Last eines "idle" Gastes war bei KVM hoeher als bei Xen, wobei
hier die Performance-Warte nichtmehr soweit auseinander sind wie bei meinem
letzten Test vor ueber einem Jahr mit KVM.
Mein Resultat daraus ist, dass man aus Performance-Sicht KVM schon betreiben
kann, muss allerdings ein bischen mehr in Hardware inverstieren als bei Xen.
Was mich sehr ueberrascht hat war die Stabilitaet von KVM! Mir hat es nur einmal
einen Gast zerlegt, aber das war beim Speichertest. Ich habe dabei auf der
Hardware, welche 8GB RAM zur Verfuegung hat, zwei Gaeste mit 8GB RAM gestartet
und danach in den Gaesten jeweils den Speicher allokiert. Da ich nur ca. 4GB
Swap konfiguriert hatte, hat mir der oom-killler dann einen Gast "entsorgt".
Hier sieht man auch wieder die Gefahren die Speicher "over-commitment" in
sich birgt!
Ich hatte KEINEN einzigen Ausfall bei Tests mit der Live-Migration! Gefuehlt
wuerde ich sagen dass die Live-Migration bei KVM ein Tick stabiler ist wie bei
Xen, was wohl aber daran liegt dass KVM per default nicht alle CPU-Features
durchreicht, waehrend Xen in der domU alle CPU-Features verfuegbar macht. Daher
muss man bei Xen aufpassen welche Hardware man einsetzt bzw. dass man auf der
Hardware mit dem kleinsten gemeinsamen Nenner nur die domUs startet. Auf der
anderen Seite kostet diese Stabilitaet Performance, da KVM im Gast dann nicht
alle CPU-Features zur Verfuegung stellt.
Ein fuer mich wichtiger Test war noch das Entfernen und Hinzufuegen von
virtuellen Festplatten im Betrieb. Hier hat KVM leider total versagt. In
Theorie ist es moeglich
(http://www.linux-kvm.org/page/Hotadd_pci_devices#Add_a_disk). In der Praxis
kann ich im Betrieb eine virtuelle Festplatte entfernen, kein Problem. Ich
kann im Betrieb eine neue virtuelle Festplatte hinzufuegen, auch kein Problem.
ABER ich kann nicht eine Festplatte entfernen und dieselbe wieder hinzufuegen!
Dabei beendet sich der Gast sofort! Es gab dazu etwas auf der Mailingliste
von kvm das ich jetzt aber spontan nichtmehr finde. Wie es aussah hatte das
keinen interessiert.
Mein Resultat daraus war, dass KVM fuer die Virtualisierung von Windows 2008
robust und performant genug ist. Ich wuerde es auch ohne zu zoegern fuer die
Desktop-Virtualisierung einsetzen.
Fuer den Betrieb von virtuellen Linux-Servern bin ich allerdings durch Xen doch
ganz schoen verwoehnt. Deshalb werde ich erstmal fuer die
Linux-Server-Virtualisierung bei Xen bleiben, vorallem da Debian squeeze wohl
doch dom0-Support haben wird:
http://womble.decadent.org.uk/blog/debian-linux-packages-the-big-bang-release
--
Gruss
\|/
eMHa (o o)
------------------------------------------------------oOO--U--OOo--
Markus Hochholdinger
e-mail mailto:Markus@... .oooO
www http://www.hochholdinger.net ( ) Oooo.
------------------------------------------------------\ (----( )-
Ich will die Welt veraendern, \_) ) /
aber Gott gibt mir den Quelltext nicht! (_/
--
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/