KVM in der Praxis

Aber ist KVM dadurch das bessere Xen? Was spricht heute für KVM, was dagegen?

Installation und Handling

KVM präsentiert sich bereits bei der Installation sehr schlank und einfach: es sind im Wesentlichen die Kernel-Module zum bestehenden System dazu zu installieren sowie Qemu und Management-Tools einzurichten. Damit kann im Gegensatz zu Xen auch ein bereits vorhandener Linux-Server nachträglich zum Virtualisierungssystem aufgerüstet werden. Bei Xen ist immer eine komplette Neuinstallation notwendig, da es sich um ein Bare-Metal System handelt.

Auch beim Handling finden sich Linux-Administratoren sofort zurecht: Jeder Gast bzw. jede virtuelle CPU verhalten sich wie ganz gewöhnliche Linux-Prozesse und können so beispielsweise auch über normale Kommandos wie z.B. top, kill usw. kontrolliert und gesteuert werden. Dies gilt auch für die Gerätelandschaft, speziell für Speichergeräte - da hier die normalen Linux-Treiber genutzt werden. Eine Umgewöhnung ist nicht nötig.

Da Gastsysteme vollständig virtualisiert werden, sind Modifikationen in selbigen nicht erforderlich. KVM unterstützt jedoch bei Bedarf auch die Paravirtualisierung von I/O-Schnittstellen (Netzwerk, Festplatte, Memory Ballooning, VGA). Hierzu nutzt es die standardisierte virtio-Schnittstelle des Linux-Kernels. Der Vorteil dieser Treiber ist der geringere Overhead und die höhere Performance.

Management

Beim Management zeigt sich der junge Charakter von KVM noch von seiner eher unpraktischen Seite. KVM ist zwar in vielen Linux-Distributionen als eine Sammlung von Paketen bereits an Bord. Zum Standard gehört hier z.B. bei Ubuntu (welches ebenfalls von Xen zu KVM umgeschwenkt ist) der grafische virt-manager sowie die Kommandozeilen-Toolbox virsh. Beide laufen auf Basis des hypervisorübergreifenden Schnittstellenpakets libvirt (welches sich auch auf Xen versteht). Remote Management ist damit möglich, jedoch keine "Orchestrierung" ganzer Pools virtueller Maschinen mit weitergehenden Funktionen wie Failover, High Availability und dergleichen.

Hier springen Drittprojekte sowie Softwarehersteller in die Bresche, typischerweise allesamt Open Source (wenngleich teilweise kostenpflichtig):

• Convirture (ehemals ConVirt, ehemals XenMan) verwaltet Pools von Xen- und KVM-Servern parallel unter einer grafischen Weboberfläche.

• oVirt: libvirt-basierende Web-GUI für das Management virtualisierter Server

• Ganeti: Cluster Virtual Server Management Software von Google

• Enomaly: Cloud Computing Plattform für KVM und Xen

• openQRM: Data-Center Management Plattform mit Xen, KVM, VMware und Linux VServer als Basis für virtualisierte Server

Aufbauend auf KVM als Virtualisierungs-Engine sind inzwischen verschiedene Komplettlösungen für Server-Virtualisierung am Markt angekommen:

• RHEV (Red Hat Virtualization): das Lösungspaket enthält Komponenten für HA, Scheduling, Migration, Energieverwaltung sowie für Monitoring. Pikanterweise hat die Open Source-only Schmiede derzeit nur ein Windows-basierendes Management-System. Dieses benötigt einen Windows 2003 Server sowie eine Windows-Workstation für die Nutzung der grafischen Konsole. Nicht nur, dass dies völlig unverständlich erscheint, es erhöht die Kosten des Gesamtsetups und es stellt auch noch einen Single Point of Failure dar, so dass man die Konstruktion insgesamt in Frage stellen darf. Eine reine Open-Source-Lösung soll jedoch in Arbeit sein.

• Proxmox VE: Out-of-the-Box Virtualisierungsplattform für KVM und openVZ

Da erst solche Komplettlösungen den breiten Markt erschließen können, ist davon auszugehen, dass in nächster Zeit weitere solcher Produkte entstehen werden, was die Popularität von KVM weiter fördern dürfte. Insgesamt wird dabei allen voran Red Hat gefordert sein, ein Ökosystem von KVM-Drittherstellern zu schaffen, welches eine Gesamtlandschaft für diesen Hypervisor schafft, um ihn Enterprise-ready zu machen.