In der Praxis

Wenn Sie das Github-Repository von Kvmtool geclont haben, kann es gleich mit dem Build losgehen. Alternativ können Sie Kvmtool auch aus dem Repository Ihrer Linux-Distribution installieren. Wenn Sie auch eine grafische Konsole haben möchten, brauchen Sie auch die Header-Files von SDL oder GTK 3. Der Build von kvmtool erschöpft sich dann in einem Aufruf von "make", an dessen Ende ein Binary namens "lkvm" herauskommt. Um die verfügbaren Optionen zu erfahren, rufen Sie "./lkvm --help" auf. Es gibt diverse Befehle, die jeweils einer der Dateien "builtin-*.c" entsprechen. Um eine VM zu starten, rufen Sie "lkvm run" auf. Es führt den Gast auf demselben Kernel aus, der auf dem Host läuft, also muss das zugehörige Kernel-Image "/boot/vmlinuz…" lesbar sein. Auf Ubuntu zum Beispiel darf nur Root diese Files lesen. Außerdem muss der Gast-Kernel bestimmte Features wie VirtIO unterstützen und braucht dazu die entsprechenden Module aus der Initial RAM-Disk (initrd).

Schließlich braucht lkvm auch noch ein Disk-Image für den Gast. Per Default ist dies ein kleines Root-FS, das lkvm im Verzeichnis "~/.lkvm/default" des Host-Systems erzeugt und als 9P-Dateisystem exportiert. 9P ist ein Netzwerkdateisystemprotokoll, das vom Betriebssystem Plan 9 stammt und auch von Qemu verwendet wird, um Verzeichnisse zwischen Gast und Host zu sharen. Eine Alternative dazu ist, eins der fertigen Test-Images von Qemu [5] zu verwenden, zum Beispiel "linux-0.2.img". Damit sieht ein vollständiger Kvmtool-Aufruf beispielsweise so aus:

./lkvm run --kernel /boot/vmlinuz-4.8.0-46-generic --initrd /boot/initrd.img-4.8.0-46-generic --disk /boot/linux-0.2.img --cpus 2 --sdl

lkvm benötigt an sich keine Root-Rechte, aber wie schon erwähnt, sind sie eventuell nötig, um auf dem Host-System die benötigten Kernel- oder nitrd-Dateien zu lesen. Hier setzt "--cpus 2" die Anzahl der vCPUs auf 2 und "--sdl" weist kvmtool an, ein SDL-Fenster zu öffnen (Abbildung 3). Mit "--name" vergeben Sie einen Namen, den Sie verwenden können, um die gestartete VM zu managen. Ansonsten erzeugt Kvmtool einen zufälligen wie etwa "guest-4361".

Abbildung 3: Um ein Ausgabefenster für die VM zu bekommen, brauchen Sie SDL (hier zu sehen), VNC oder GTK.

Debugging

Obwohl Kvmtool ein super Tool ist, um die Funktion von KVM-Virtualisierung zu verstehen, setzen doch die meisten produktiv Qemu ein. Es gibt allerdings einen Anwendungsfall, für den sich Kvmtool besonders gut eignet, nämlich das Debugging von Boot-Problemen. So bietet Kvmtool einige Switches, die eine solche Fehlersuche unterstützen, zum Beispiel Single Stepping mit "--debug-single-step". Kvmtool gibt damit nach jeder Maschinencode-Anweisung den Systemzustand aus (Abbildung 4), was das System natürlich extrem verlangsamt. Dann gibt es noch einen speziell für Debugging ausgerichteten Befehl namens "debug", den Sie so verwenden:

./lkvm debug --name guest-4849 --dump

Abbildung 4: Zum Debugging dumpt Kvmtool den aktuellen Maschinenzustand.

Auch hier gibt Kvmtool wieder den Systemzustand aus. Intern schickt es das SIGUSR1-Signal an den vCPU-Thread, um die Interna wie die Register von KVM zu erfahren. Es ist außerdem möglich einen nicht-maskierbaren Interrupt (NMI) an den Gast zu schicken:

./lkvm debug --name guest-4849 --nmi 0

Der Wert hinter dem Schalter ist die vCPU-Nummer, an die der NMI geschickt werden soll. NMIs sind schweres Geschütz und werden vom Kernel entsprechend quittiert, wenn sie unerwartet auftreten. Ansonsten sind sie häufig die einzige Option einen nicht mehr reagierenden Kernel anzusprechen.

Infos[1] Virtio v1.0: http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html

[2] Kvmtool homepage: https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/about/

[3] Running rkt with KVM stage1: https://coreos.com/rkt/docs/latest/running-kvm-stage1.html

[4] 7 ways we harden our KVM hypervisor at Google Cloud: https://cloudplatform.googleblog.com/2017/01/7-ways-we-harden-our-KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html

[5] Testing/System Images at Qemu wiki: http://wiki.qemu-project.org/Testing/System_Images