[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

KVM im Test

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@xxxxxxxxxxxxxxxxx             .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/