Virtio-SCSI

Selbstverständlich haben die Red-Hat-Entwickler die Gelegenheit genutzt, auch KVM selbst in vielen Bereichen zu überarbeiten und die offiziell nur im aktuellen Kernel 3.4 enthaltenen Neuerungen am KVM-Code auch im Fedora-Kernel verfügbar gemacht. So enthält KVM jetzt eine virtualisierte PMU (Performance Monitoring Unit) für Gäste sowie eine Live-Block-Kopierfunktion, mit deren Hilfe sich Speichermedien von Gastsystemen kopieren lassen, während diese online sind. Installiert der Admin beispielsweise das Paket »Guest filesystem browser« und »System administration tools for virtual machines« , kann er mit einer grafischen GUI das Gast-Filesystem über den entsprechenden KVM-Treiber inspizieren ( Abbildung 3 ). Zum weiteren Experimentieren mit KVM muss der Admin außerdem das Paket »QEMU metapackages for KVM support« installieren.

Abbildung 3: Fedora ist im Virtualisierungsbereich bestens ausgestattet, wenn auch keines der Pakete per Default installiert ist.

PCI-2.3-Geräte kann das neue Fedora an Gäste durchreichen. Diese teilen sich dann auf dem Host eine Interrupt-Leitung mit anderen PCI-Geräten. Die in Fedora 17 enthaltene KVM-Version enthält außerdem das ebenfalls offiziell nur im Kernel 3.4 vorhandene Virtio-SCSI, ein neuer SCSI-Storage-Stack für KVM-Gastsysteme. Der neue Storage-Treiber für das SCSI-Subsystem regelt zusammen mit der gleichlautenden Qemu-Unterstützung den Datenverkehr zwischen Gast und Host gegenüber dem bisherigen "virtio-blk"-Treiber mit weniger Overhead, skaliert besser und ist einfacher zu handhaben. Andere Distributionen werden KVM-Virtio-SCSI erst mit Integration des Kernel 3.4 anbieten können.

Virtsandbox

Fedora 17 bringt als eine der ersten Distributionen die von Red Hat entwickelte Bibliothek Libvirt-Sandbox [5] mit, die Daniel Berrange im Februar dieses Jahres auf der FOSDEM in Brüssel vorgestellt hat. Sie erlaubt das Einsperren einzelner Applikationen mithilfe von KVM oder wahlweise auch mit LXC in eine abgesicherte Sandbox. Der Clou dabei ist, dass das explizite Einrichten des Betriebssystems in der VM nicht notwendig und der Overhead damit sehr klein ist.

In der Variante auf Basis von KVM startet Virtsandbox den Kernel samt Initramfs in einer VM, die ihrerseits nach dem Booten die eigentliche Anwendung aufruft. Da der Kernel der VM mithilfe des Qemu-Features Plan9fs (Plan 9 File System, [6] ) Teile des Host-Dateisystems lesen kann, entfällt die Betriebssystem-Installation in der VM, sodass der zeitliche Aufwand beim Starten einer mithilfe der Libvirt-Sandbox eingesperrten Anwendung laut Daniel Berrange kaum ins Gewicht fällt. Laut Red Hats Messungen verzögert sich der Start einer Anwendung in der geschützten Virtsandbox um maximal 3 Sekunden gegenüber dem nativen Start. Bei der Virtsandbox-Methode soll laut Red Hat der Zugriff auf die CPU weitgehend ohne Performance-Einbußen erfolgen, während der Zugriff auf Geräte nur mit knapp 90 Prozent der Geschwindigkeit (gegenüber dem nativen Ausführen der gleichen Anwendung) erfolgt.

Das Einrichten der Sandbox erfolgt über das CLI-Tool »virt-sandbox« , mit dessen Hilfe der Admin beispielsweise festlegt, ob oder welche Netzwerk-Ressourcen in der Sandbox zur Verfügung stehen, nachdem er »libvirt-sandbox« via »yum install libvirt-sandbox« installiert hat.