41KVM
Seit KVM (Kernel-based Virtual Machine) 2007 in den offiziellen Kernelcode integriert wurde, hat sich diese Linux-spezifische Virtualisierungstechnik vor allem im Server- und Enterprise-Segment etabliert. Red Hat und SUSE setzen in ihren Enterprise-Distributionen voll auf KVM, und auch alle anderen gängigen Linux-Distributionen enthalten KVM-Pakete.
Dieses Kapitel führt zuerst in die Grundlagen von KVM ein und konzentriert sich dann auf die Server-Virtualisierung mit KVM: Damit können auf einem Rechner mehrere virtuelle Linux-Server laufen. In der Praxis wird das häufig gemacht, um die Server-Funktionen so gut wie möglich voneinander zu trennen und so die Sicherheit zu maximieren. Aber auch praktische Gründe sprechen oft für die Server-Virtualisierung: Während der eine Anwender für seine Website spezielle Apache-Module braucht, will ein anderer die neueste MySQL-Version einsetzen. Wenn viele derartige Sonderwünsche auf einem System erfüllt werden, führt das rasch zu unerwünschten Nebenwirkungen und Instabilitäten.
KVM ist prinzipiell auch zur Desktop-Virtualisierung geeignet, dieser Aspekt steht hier aber im Hintergrund. Für den Desktop-Einsatz empfehle ich Ihnen VirtualBox, das einfacher zu bedienen ist. Sollten Sie dennoch KVM auf Desktop-Systemen einsetzen wollen, können Sie einen Blick auf das Gnome-Programm »Boxes« werfen: Wie bei Gnome typisch, ist die Bedienung sehr einfach, allerdings bietet das Programm selbst für einfache Anwendungen zu wenige Konfigurationsmöglichkeiten.
Dieses Kapitel kann nur eine Einführung in KVM geben. Weitere Informationen finden Sie hier:
http://www.linux-kvm.org
http://libvirt.org
https://help.ubuntu.com/community/KVM
https://access.redhat.com/documentation/en/red-hat-enterprise-linux
41.1Grundlagen
Das Programm QEMU emuliert verschiedene CPUs und elementare Hardware-Komponenten eines Rechners, also seine Netzwerkkarte, ein DVD-Laufwerk für die Installation etc. QEMU ist auch in der Lage, zur Wirts-CPU inkompatible Prozessoren zu emulieren (ARM, Sparc, PowerPC, MIPS etc.).
KVM ist ein Kernelmodul, das seine Wirkung erst in Kombination mit QEMU entfaltet. KVM setzt eine CPU mit Funktionen zur Hardware-Virtualisierung voraus und macht aus dem Emulator QEMU ein Hardware-Virtualisierungssystem. Die Eleganz von KVM besteht darin, dass es typische Hypervisor-Aufgaben nicht selbst ausführt, sondern dazu auf Speicher- und Prozessverwaltungsfunktionen des Linux-Kernels zurückgreift. Die Nutzung der KVM-Funktionen erfolgt über die Device-Datei /dev/kvm.
KVM funktioniert nur, wenn der Prozessor des Host-Systems Virtualisierungsfunktionen unterstützt (Intel-VT bzw. AMD-V). Das ist bei den meisten aktuellen Prozessoren der Fall. Zu den Ausnahmen zählen sehr preisgünstige CPUs für Billig-PCs bzw. -Notebooks sowie die Atom-Prozessoren von Intel. Um festzustellen, ob Ihre CPU bei der Hardware-Virtualisierung hilft (Intel-VT oder AMD-V), führen Sie das folgende egrep-Kommando aus. Wenn das Ergebnis leer ist, unterstützt Ihre CPU keine Virtualisierung oder die Funktion wurde im BIOS/EFI deaktiviert.
Bei Ubuntu-Systemen können Sie – noch einfacher – das Kommando kvm-ok aus dem Paket cpu-checker ausführen:
Im weiteren Verlauf dieses Kapitels setze ich voraus, dass Ihre CPU KVM-kompatibel ist. Sollte das nicht der Fall sein, funktioniert KVM scheinbar auch. Tatsächlich werden die virtuellen Maschinen aber nur durch QEMU und somit ohne KVM-Unterstützung ausgeführt und laufen dann wesentlich langsamer.
Virtualisierungsfunktionen im BIOS/EFI aktivieren
Erstaunlicherweise sind die vorhandenen Virtualisierungsfunktionen der CPU durch das BIOS oder EFI deaktiviert. Abhilfe: Öffnen Sie beim Rechnerstart die BIOS/EFI-Dialoge, und suchen Sie nach der betreffenden Einstellung.
KVM stellt seine Funktionen in drei Kernelmodulen zur Verfügung: Die Grundfunktionen befinden sich im Modul kvm, die Intel-VT-spezifischen Funktionen in kvm-intel, die AMD-V-spezifischen Funktionen in kvm-amd. Damit Sie KVM nutzen können, muss das zu Ihrer Hardware passende KVM-Modul geladen werden. Das Modul kvm wird dabei gleich mitgeladen. Bei den meisten Distributionen kümmert sich das Init-System darum. Sollte das nicht funktionieren, greifen Sie manuell ein:
Um eine virtuelle Maschine mit QEMU oder KVM auszuführen, können Sie direkt das KVM-Kommando ausführen. Es wird je nach Distribution unterschiedlich angesprochen (siehe Tabelle 41.1).
|
Distribution |
Paket |
KVM-Kommando |
|---|---|---|
|
CentOS/RHEL |
qemu-kvm |
/usr/libexec/qemu-kvm |
|
Debian |
qemu-kvm |
kvm |
|
Fedora |
qemu-kvm |
qemu-kvm |
|
openSUSE |
kvm |
qemu-kvm |
|
Ubuntu |
qemu-kvm |
kvm |
Tabelle 41.1KVM-Paketname und -Kommandoname
Nach dem Start des KVM-Kommandos wird die virtuelle Maschine in einem Fenster angezeigt oder muss durch einen VNC-Client gesteuert werden. Generell ist der direkte Einsatz des KVM-Kommandos aber selten zu empfehlen: Sie müssen die Hardware-Komponenten der virtuellen Maschine durch unzählige Optionen einstellen. Das macht den Einsatz von KVM unübersichtlich und fehleranfällig.
Der Einsatz der diversen libvirt-Werkzeuge vereinfacht die Administration virtueller Maschinen erheblich:
-
Der Virtual Machine Manager (Programm- bzw. Paketname virt-manager) hilft mit einer grafischen Benutzeroberfläche beim Einrichten und Ausführen virtueller Maschinen.
-
Wenn Sie lieber im Terminal arbeiten, können Sie mit der Shell virsh virtuelle Maschinen erzeugen, starten und wieder stoppen sowie andere Administrationsarbeiten durchführen.
-
Daneben gibt es diverse Kommandos für Spezialaufgaben: virt-clone kopiert eine virtuelle Maschine, virt-top liefert ähnlich wie top eine Auflistung aller virtuellen Maschinen samt RAM- und CPU-Nutzung etc.
Alle gängigen Distributionen stellen KVM- und libvirt-Pakete zur Verfügung. Da die Entwicklung von KVM aber in einem sehr hohen Ausmaß von Red Hat betrieben wird, eignen sich RHEL oder RHEL-Clones wie CentOS besonders gut für den KVM-Einsatz. Wenn Sie die allerneuesten KVM-Features testen möchten, ist Fedora die ideale Spielwiese.
Natürlich können Sie auch mit anderen Distributionen arbeiten, Sie müssen sich dann aber damit abfinden, dass neue KVM-Funktionen nicht oder nur eingeschränkt nutzbar sind. Beispielsweise sind die libvirt-Werkzeuge in Ubuntu 12.04 nicht Spice-kompatibel, obwohl dieses besonders effiziente virtuelle Grafiksystem in wesentlich älteren RHEL-Versionen problemlos läuft, auch im Virtual Machine Manager.
Beachten Sie, dass Red Hat KVM-Pakete nur mit der 64-Bit-Version seiner Enterprise-Distribution ausliefert. Auf einem Virtualisierungs-Host sollte der Einsatz einer 64-Bit-Installation aber ohnedies selbstverständlich sein.
Um virtuelle KVM-Maschinen auszuführen und mit den libvirt-Werkzeugen steuern zu können, müssen Sie die folgenden Pakete installieren:
libvirt-Interna
libvirt ist eine Schnittstelle zur Verwaltung von virtuellen Maschinen und der dazugehörigen virtuellen Netzwerk- und Festplatten-Devices. Eine Voraussetzung für die Nutzung der libvirt-Werkzeuge besteht darin, dass auf dem Hostsystem der Dämon libvirtd läuft. Dieses Programm wird beim Hochfahren des Hostrechners durch das Init-System gestartet.
Die Steuerung der virtuellen Maschinen erfolgt wahlweise durch die Shell virsh, den Virtual Machine Manager oder durch andere libvirt-Kommandos. Jedes dieser Programme muss vorher eine Verbindung zum libvirt-Dämon herstellen. Der libvirt-Dämon erlaubt auch Netzwerkverbindungen, die üblicherweise durch SSH getunnelt werden.
Die libvirt-Werkzeuge können neben KVM auch das Virtualisierungssystem Xen steuern. In diesem Kapitel beziehe ich mich aber ausschließlich auf KVM.
KVM-Maschinen können via libvirt auf zwei Ebenen ausgeführt werden:
-
Benutzerebene (qemu:///session): Diese Variante ist vor allem für die Desktop-Virtualisierung gedacht und gibt den virtuellen Maschinen weniger Zugriffsmöglichkeiten auf die Hardware des Hostrechners. Intern wird beim ersten Aufruf eines libvirt-Werkzeugs auf Benutzerebene ein eigener libvirtd-Prozess gestartet, dem nur die Rechte des aktuellen Benutzers zukommen. KVM-Maschien auf Benutzerebene minimieren also die Sicherheitsrisiken durch die Virtualisierung.
-
Systemebene (qemu:///system): Virtuelle Maschinen auf Systemebene sind besser für die Server-Virtualisierung geeignet, weil sie direkt auf Hardware-Komponenten des Hostrechners zugreifen können und mehr Möglichkeiten zur Integration der virtuellen Maschinen in das Netzwerk bestehen. Die libvirt-Prozesse kommunizieren dabei mit dem Dämon libvirtd, der mit root-Rechten läuft.
Bei der Kommunikation zwischen den libvirt-Werkzeugen und dem Dämon libvirtd bestehen starke Konfigurationsunterschiede zwischen den Distributionen. Ganz einfach ist es bei CentOS, Fedora und RHEL: Wenn Sie mit libvirtd auf Systemebene kommunizieren möchten, benötigen Sie root-Rechte. Der Virtual Machine Manager kann zwar mit Benutzerrechten gestartet werden, das Programm erwartet aber unmittelbar nach dem Start die Angabe des root-Passworts.
Beachten Sie dabei, dass zwar die libvirt-Werkzeuge mit root-Rechten ausgeführt werden, nicht aber das eigentliche Virtualisierungskommando! Vielmehr starten die libvirt-Werkzeuge das Kommando qemu-kvm unter dem Benutzeraccount qemu. Auf diese Feinheit müssen Sie vor allem bei der richtigen Einstellung der Zugriffsrechte für Image- oder ISO-Dateien achten!
Auch unter Ubuntu kommunizieren libvirt-Werkzeuge, die mit root-Rechten ausgeführt werden, mit libvirtd auf Systemebene. Aber auch libvirt-Kommandos, die nur mit Benutzerrechten ausgeführt werden, dürfen mit libvirtd auf Systemebene kommunizieren, sofern der Benutzer der Gruppe libvirtd angehört! Genau genommen ist entscheidend, ob der Benutzer auf die Datei /var/run/libvirt/libvirt-sock zugreifen darf. Diese Datei gehört root und der Gruppe libvirtd.
Die Zuordnung zur Gruppe libvirtd wird bei der Installation des Pakets libvirt-bin automatisch für den Benutzer hergestellt, der die Installation durchführt. Weitere Benutzer können mit dem folgenden Kommando der libvirtd-Gruppe hinzugefügt werden:
Debian verhält sich bei der libvirt-Konfiguration anders als Ubuntu: Dort haben alle Benutzer Lese- und Schreibrechte auf /var/run/libvirt/libvirt-sock. Eine Gruppenzuordnung ist deswegen nicht erforderlich.
Die Konfigurationsdateien des libvirt-Systems befinden sich im Verzeichnis /etc/libvirt. Besonders interessant ist die in diesem Verzeichnis enthaltene Datei qemu.conf: Sie gibt diverse Grundeinstellungen für das KVM-Kommando vor. Die Datei steuert unter anderem die Defaulteinstellungen des VNC- bzw. Spice-Servers der virtuellen Maschine. Dabei kommt standardmäßig die IP-Adresse 127.0.0.1 zum Einsatz. Somit sind nur lokale Verbindungen zulässig, wobei eine Weiterleitung via SSH Port Forwarding möglich ist.
Außerdem werden die Eigenschaften jeder virtuellen Maschine in einer XML-Datei im Verzeichnis /etc/libvirt/qemu festgehalten. Die meisten Einstellungen sind ohne weitere Erklärung verständlich und korrespondieren direkt mit entsprechenden KVM-Optionen. Im Detail ist das Format der libvirt-XML-Dateien auf folgender Seite dokumentiert:
http://libvirt.org/format.html
Ändern Sie die Beschreibung virtueller Maschinen immer durch »virsh edit«!
Sie sollten die XML-Dateien mit den Eckdaten einer virtuellen Maschine nicht direkt mit einem Editor ändern – sonst kann es passieren, dass ein anderes libvirt-Werkzeug Ihre Änderungen überschreibt. Verwenden Sie stattdessen das virsh-Kommando edit!
Wenn Sie beim Einrichten virtueller Maschinen auf Disk Images zur Abbildung der virtuellen Datenträger zurückgreifen, werden diese standardmäßig im Verzeichnis /var/lib/libvirt/images gespeichert. Wenn Sie Disk Images in einem anderen Verzeichnis speichern möchten oder Logicial Volumes, Festplattenpartitionen oder Netzwerkgeräte zur Speicherung der Datenträger nutzen möchten, müssen Sie vorher einen sogenannten Storage Pool einrichten. Am einfachsten gelingt das im Virtual Machine Manager. Alternativ führen Sie die entsprechenden pool-Kommandos innerhalb von virsh aus.
Verhalten beim Neustart des Hostsystems
Was passiert mit den virtuellen Maschinen, wenn Sie das Hostsystem herunterfahren?
-
CentOS, Fedora und RHEL sichern mit dem virsh-Kommando save den Speicherinhalt aller durch libvirtd auf Systemebene ausgeführten virtuellen Maschinen. Beim nächsten Start des Rechners wird der Zustand der virtuellen Maschinen automatisch wiederhergestellt (restore), d.h., die virtuellen Maschinen laufen weiter, als wäre in der Zwischenzeit nichts passiert.
Verantwortlich für diesen Mechanismus ist das Script /usr/libexec/libvirt-guests.sh, das vom Systemd-Service libvirt-guests aufgerufen wird. Einige Konfigurationsparameter können Sie in /etc/sysconfig/libvirt-guests einstellen.
Bei der Sicherung bzw. Wiederherstellung mehrerer virtueller Maschinen muss jeweils deren gesamtes RAM auf der Festplatte gespeichert bzw. von dort gelesen werden. Das setzt ausreichend freien Speicherplatz im Verzeichnis /var/lib/libvirt/qemu/save voraus und dauert natürlich einige Zeit.
-
Aktuelle Debian- und SUSE-Distributionen agieren ähnlich. Das entsprechende Script befindet sich in /usr/lib64/libvirt/libvirt-guests.sh.
-
Ubuntu versucht beim Herunterfahren, alle laufenden virtuellen Maschinen durch das virsh-Kommando shutdown herunterzufahren. Wenn das nicht gelingt bzw. wenn die virtuellen Maschinen sich für ein geordnetes Ende zu viel Zeit nehmen, werden sie gewaltsam durch das virsh-Kommando destroy beendet. Der dafür verantwortliche Code befindet sich bei älteren Ubuntu-Versionen in der Upstart-Konfigurationsdatei /etc/init/libvirt-bin.conf. Bei aktuellen Ubuntu-Versionen ist für das Herunterfahren das Script /usr/lib/libvirt/libvirt-stop-guests verantwortlich. Es wird durch Systemd ausgeführt.
Virtuelle Hardware
Beim Einrichten einer neuen virtuellen Maschine haben Sie eine Menge Wahlmöglichkeiten: Disk-Images im RAW- oder im QCOW2-Format, IDE- oder virtio-Festplattenadapter, das Grafiksystem auf der Basis von SDL, VNC oder Spice etc. Dieser Abschnitt fasst dazu die wichtigsten Informationen zusammen.
Grundsätzlich führt KVM eine vollständige Virtualisierung durch. Das in der virtuellen Maschine laufende Gastsystem benötigt also keine besonderen Treiber.
Das Gastsystem kann freilich noch effizienter ausgeführt werden, wenn zur Kommunikation zwischen KVM und der virtuellen Maschine die optionalen virtio-Treiber zum Einsatz kommen. In der Fachsprache ist dann von »Paravirtualisierung« die Rede, d.h., das Gastsystem hilft gewissermaßen bei der Virtualisierung mit.
Bei Linux-Gästen stehen standardmäßig drei virtio-Treiber zur Beschleunigung von Festplatten-, Speicher- und Netzwerkzugriffen zur Verfügung. Es geht also nur darum, beim Einrichten der virtuellen Maschine die entsprechenden virtio-Komponenten auszuwählen.
Ein wenig diffiziler ist die Angelegenheit, wenn Sie Windows in einer KVM-Maschine ausführen möchten: In diesem Fall richten Sie die virtuelle Maschine zuerst mit traditionellen Hardware-Komponenten ein, also z.B. mit einer virtuellen IDE-Schnittstelle. Nach der Installation von Windows installieren Sie die virtio-Treiber, und erst dann können Sie die virtio-Komponenten durch eine nachträgliche Veränderung der virtuellen Maschine aktivieren.
Um einem Gast eine virtuelle Festplatte anzubieten, wird häufig auf dem KVM-Host eine Image-Datei verwendet. Dabei unterstützen QEMU/KVM drei Image-Formate:
-
RAW-Format: Beim RAW-Format werden die Blöcke der virtuellen Festplatte einfach 1:1 abgebildet. Sofern das Dateisystem des Hostrechners sogenannte Sparse Files unterstützt, werden Blöcke, die ausschließlich Nullen enthalten, nicht physikalisch gespeichert. Das funktioniert so unter anderem bei ext-, xfs- und btrfs-Dateisystemen und spart anfänglich eine Menge Platz. Das RAW-Format ist das einfachste und schnellste Image-Format für virtuelle Maschinen.
-
QCOW2-Format: QCOW2 steht für Qemu Copy-on-Write, Version 2. Dieses Format bietet gegenüber RAW eine Menge Zusatzfunktionen: Die Datenblöcke werden erst bei Bedarf reserviert, ohne ein Sparse-kompatibles Dateisystem vorauszusetzen. Außerdem kann das virtuelle Dateisystem komprimiert und verschlüsselt werden. Außerdem bieten QCOW2-Images die Möglichkeit, Snapshots zu verwalten. QCOW2-Images sind langsamer als RAW-Images, der Geschwindigkeitsnachteil ist aber nicht mehr so groß wie in der Vergangenheit. QCOW2 ist seit mehreren Jahren das Default-Dateisystem des Virtual Machine Managers.
-
QED-Format: Das QEMU Enhanced Disk Format, kurz QED, liegt in seiner Geschwindigkeit zwischen RAW und QCOW2. Das Format bietet aber weniger Funktionen als QCOW2. Insbesondere fehlt die praktische Snapshot-Funktion.
Anstelle von Image-Dateien können Sie auch Festplattenpartitionen, Logical Volumes oder iSCSI-Devices als virtuelle Festplatten nutzen. Diese Varianten bieten in großen Virtualisierungssystemen administrative Vorteile, aber keine nennenswert höhere Geschwindigkeit im Vergleich zu RAW-Images.
Um die virtuelle Maschine mit dem lokalen Netzwerk oder dem Internet verbinden zu können, müssen Sie sie mit einem Netzwerkadapter ausstatten. Bei Linux-Gästen ist der virtio-Treiber die erste Wahl. Bei Windows-Gästen haben Sie unter anderem die Wahl zwischen einem RTL-8139- oder einem Intel-E1000-Netzwerkadapter.
Die zweite Frage ist, wie Sie den Adapter mit Ihrem Netzwerk verbinden:
-
NAT: Standardmäßig entscheiden sich das KVM-Kommando bzw. die libvirt-Werkzeuge für die NAT-Variante, also für Network Address Translation. Damit wird der Internetzugang des Hosts an den Gast weitergeleitet. Der Gast ist aber weder im lokalen Netzwerk noch im Internet sichtbar.
-
Netzwerkbrücken: Für den Server-Einsatz müssen Sie die virtuelle Maschine durch eine Netzwerkbrücke oder durch Routing mit dem Netzwerk bzw. Internet verbinden. Das erfordert eine spezielle Netzwerkkonfiguration des KVM-Hosts.
-
MacVTap: Aktuelle Versionen der libvirt-Werkzeuge unterstützen mit MacVTap-Devices eine dritte Variante, bei der ein virtueller Netzwerkadapter mit einem physischen verbunden wird.
Zumindest während der Installation müssen Sie die Ausgaben der virtuellen Maschine sehen. Der Gast braucht also ein eigenes Grafiksystem. Dazu wird eine VGA-kompatible Grafikkarte emuliert, deren Ausgaben dann via VNC oder Spice in einem Fenster angezeigt werden. Für den 2D-Einsatz funktioniert dies selbst in hoher Auflösung gut. KVM bietet zurzeit aber keine Unterstützung für 3D-Funktionen.
VNC und Spice sind netzwerktauglich. Für die relativ neue Spice-Architektur sprechen die etwas höhere Geschwindigkeit und der Umstand, dass auch Audio-Ausgaben der virtuellen Maschine über das Netzwerk an den lokalen Spice-Client weitergeleitet werden können. Gegen Spice spricht die schlechte Verfügbarkeit von Spice-Clients außerhalb der Linux-Welt.