KVM im Test

Autor: Markus Hochholdinger <Markus_at_hochholdinger.net>
Datum: Thu, 25 Mar 2010 15:59:12 +0100
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 für Windows 2008 testen sollte - was man nicht alles tut...

Für meine KVM-Tests habe ich Debian squeeze verwendet mit Kernel 2.6.32 und 
qemu-kvm 0.11.
Ich habe zwei Stück Hardware (Pentium D 3GHz) für die Tests gehabt auf welchen 
ich zuerst mein Standard-Setup (Xen-Cluster) mit Debian lenny eingerichtet 
habe und Performance-Tests durchgeführt habe. Hier habe ich allerdings nur 
Linux-domUs (Gäste) getestet, da die Unterstützung von HVM bei Debian lenny 
nicht so toll ist (z.B. keine Live-Migration möglich). 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 
für Festplatten und Netzwerkkarten in den Gästen verwenden, ansonsten ist die 
Performance natürlich sehr schlecht und quasi gleichlangsam wie mit dem 
reinen qemu (ohne Kernel-Modul).
Ich habe kurze Tests mit aktiviertem KSM (Kernel Samepage Merging) 
durchgeführt, 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" lässt, für 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 Gäste allokieren den Speicher auch erst, wenn sie diesen benötigen.
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) verfügbar sein! Ein 
Speicher "over-commitment" ist bei Xen (momentan) nicht möglich.
Man kann sich nun darüber streiten ob das gut oder schlecht ist. Persönlich 
finde ich den Ansatz von Xen stabiler aber halt auch unflexibler.

Zur Verwaltung der KVM-Gäste 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 Gäste unter KVM möglichst mit denselben Bedingungen wie 
unter Xen zu betreiben.

Ich habe es dann auch geschafft mit einem KVM-Gast denselben Durchsatz für 
Festplatte und Netzwerk zu bekommen wie bei einer Xen domU. Allerdings hat 
KVM eine höhere 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 
größter Test waren 64 laufende domUs auf einer, nicht dieser, Hardware.). Bei 
KVM habe ich schon bei ca. 8 gleichzeitig laufenden Gästen einen sehr starken 
Einbruch bemerkt (OK, die darunter liegende Hardware ist schon etwas älter).
Auch die CPU-Last eines "idle" Gastes war bei KVM höher als bei Xen, wobei 
hier die Performance-Warte nichtmehr soweit auseinander sind wie bei meinem 
letzten Test vor über 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 überrascht hat war die Stabilität 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 Verfügung hat, zwei Gäste mit 8GB RAM gestartet 
und danach in den Gästen 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! Gefühlt 
würde 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, während Xen in der domU alle CPU-Features verfügbar 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 Stabilität Performance, da KVM im Gast dann nicht 
alle CPU-Features zur Verfügung stellt.

Ein für mich wichtiger Test war noch das Entfernen und Hinzufügen von 
virtuellen Festplatten im Betrieb. Hier hat KVM leider total versagt. In 
Theorie ist es möglich 
(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 hinzufügen, auch kein Problem. 
ABER ich kann nicht eine Festplatte entfernen und dieselbe wieder hinzufügen! 
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 für die Virtualisierung von Windows 2008 
robust und performant genug ist. Ich würde es auch ohne zu zögern für die 
Desktop-Virtualisierung einsetzen.
Für den Betrieb von virtuellen Linux-Servern bin ich allerdings durch Xen doch 
ganz schön verwöhnt. Deshalb werde ich erstmal für 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


-- 
Gruß
                                                          \|/
       eMHa                                              (o o)
------------------------------------------------------oOO--U--OOo--
 Markus Hochholdinger
 e-mail  mailto:Markus_at_Hochholdinger.net             .oooO
 www     http://www.hochholdinger.net                (   )   Oooo.
------------------------------------------------------\ (----(   )-
Ich will die Welt verändern,                           \_)    ) /
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/

Empfangen am 25.03.2010

Dieses Archiv wurde generiert von hypermail 2.2.0 : 25.03.2010 CET