Zum Inhalt springen

Virtualisierung

Auftrag

«Unsere Server sind selbst schon VMs. Darauf sollen wieder VMs laufen?», fragt Simone Wyss. «Und das Veloatelier redet von Containern. Kannst du mir das aufschlüsseln, bevor ich es an der Generalversammlung erklären muss?»

Lernziele

Nach diesem Kapitel kannst du:

  • Hypervisoren vom Typ 1 und Typ 2 unterscheiden
  • Erklären, wie KVM, QEMU und libvirt zusammenarbeiten
  • Die Virtualisierungsfunktionen einer CPU prüfen
  • Verschachtelte Virtualisierung und die Rolle des CPU-Modells erklären
  • VMs und Container vergleichen

Ein Hypervisor teilt einen physischen Rechner in mehrere virtuelle Maschinen auf. Jede VM erhält eigene virtuelle CPUs, eigenen Arbeitsspeicher, eigene Disks und Netzwerkkarten und führt darauf ein vollständiges Betriebssystem aus.

Ein Hypervisor vom Typ 1 läuft direkt auf der Hardware. Beispiele sind VMware ESXi, Hyper-V und KVM. Ein Hypervisor vom Typ 2 läuft als Programm in einem gewöhnlichen Betriebssystem, wie VirtualBox oder VMware Workstation. Im Rechenzentrum ist Typ 1 üblich, weil er die Hardware direkt verwaltet, ohne den Umweg über ein weiteres Betriebssystem.

Auf den Knoten deines Labs arbeiten drei Bausteine zusammen. KVM (Kernel-based Virtual Machine) ist ein Teil des Linux-Kernels und macht Linux zum Hypervisor vom Typ 1. Es nutzt die Virtualisierungsfunktionen der CPU, damit der Code einer VM direkt auf dem Prozessor läuft. QEMU läuft für jede VM als eigener Prozess und stellt ihr die übrigen Geräte bereit, also Disks, Netzwerkkarten und Konsole. Die VMs eines Rechners verwaltet libvirt über eine einheitliche Schnittstelle. OpenNebula spricht auf jedem Knoten mit libvirt, libvirt startet QEMU, QEMU nutzt KVM.

Moderne Prozessoren haben eigene Befehle für die Virtualisierung, bei Intel heissen sie VT-x, bei AMD AMD-V. Linux zeigt sie in /proc/cpuinfo als Flag vmx oder svm. Dazu kommen Funktionen wie EPT bei Intel und NPT bei AMD, mit denen die CPU die Speicheradressen der VMs schnell übersetzt. Ohne diese Unterstützung müsste QEMU jeden Befehl der VM in Software nachbilden, was die VM um ein Vielfaches verlangsamen würde.

Terminal-Fenster
lscpu | grep -iE 'virtualization|model name'

In deinem Lab stapeln sich die Hypervisoren. Deine Knoten laufen als VMs auf smartlearn. Auf ihnen führt KVM wiederum die VMs deiner Cloud aus. Damit das funktioniert, muss der äussere Hypervisor die Virtualisierungsfunktionen der CPU an die Knoten weitergeben. Dieses Prinzip heisst verschachtelte Virtualisierung. Es kostet etwas Leistung, besonders bei vielen Wechseln zwischen VM und Hypervisor, reicht für ein Lab aber gut aus. In Produktion laufen die Knoten einer Cloud direkt auf der Hardware.

Hypervisoren und verschachtelte Virtualisierung Drei Stapel nebeneinander, jeder steht auf seiner Hardware. Ein Hypervisor vom Typ 1 wie ESXi, Hyper-V oder KVM läuft direkt auf der Hardware. Die VMs laufen darauf. Ein Hypervisor vom Typ 2 wie VirtualBox oder VMware Workstation läuft als Programm in einem Betriebssystem. Im Lab sind drei Ebenen verschachtelt. Auf smartlearn oder einem eigenen Hypervisor laufen die Knoten als VMs. Auf den Knoten führt KVM die VMs deiner Cloud aus. Die Knoten sind also VMs und zugleich Hypervisoren. TYP 1 direkt auf der Hardware Hardware Hypervisor ESXi, Hyper-V, KVM VM VM TYP 2 als Programm im Betriebssystem Hardware Betriebssystem Hypervisor VirtualBox, VMware Workstation VM VM IM LAB drei Ebenen verschachtelt Hardware smartlearn oder eigener Hypervisor Knoten 1 und 2 VMs mit KVM VM VM

Ein Hypervisor zeigt einer VM nicht zwingend die echte CPU. Er kann ihr ein allgemeines Modell vorspielen, das auf vielen Rechnern gleich aussieht. Das erleichtert es, eine VM im laufenden Betrieb auf einen anderen Knoten mit anderer CPU zu verschieben. Dafür fehlen dem allgemeinen Modell manche Befehle. Bei QEMU sind das zum Beispiel die Vektorbefehle AVX2, die Programme für Berechnungen nutzen.

Bei der Entwicklung des Kurses lief ein Sprachmodell mit drei Milliarden Parametern in einer VM mit dem allgemeinen CPU-Modell und schaffte 2,2 Tokens pro Sekunde. Mit dem CPU-Modell host-passthrough, das der VM die echte CPU zeigt, waren es 19,4 Tokens pro Sekunde, fast neunmal so viel. Deshalb erhalten die VMs, auf denen in den Zusatzaufträgen von Teil 5 das Sprachmodell läuft, das CPU-Modell host-passthrough.

Ein Container ist ein Prozess mit eigener Sicht auf Dateisystem, Netz und Prozesse. Er teilt sich den Kernel mit dem Rechner, auf dem er läuft. Mitbringen muss er nur die Programme und Bibliotheken seiner Anwendung. Eine VM bringt dagegen ein vollständiges Betriebssystem mit eigenem Kernel mit.

EigenschaftVMContainer
Kerneleigenergeteilt mit dem Rechner
StartSekunden bis Minutenmeist unter einer Sekunde
GrösseGigabytesoft Megabytes
Trennungstark, durch den Hypervisorschwächer, durch Funktionen des Kernels
Typisch fürganze Server, unterschiedliche Betriebssysteme, Mandanteneinzelne Anwendungen und ihre Teile

Im Kurs kommen beide vor. OpenNebula liefert den Mitgliedern VMs, weil die Trennung zwischen Mandanten stark sein soll. Der Webshop des Veloateliers läuft in Containern auf Kubernetes. Kubernetes selbst läuft in zwei VMs aus OpenNebula.

Aufgabe Lab

Führe lscpu auf einem Knoten und auf dem Front-end aus. Welche Virtualisierung meldet lscpu? Welches CPU-Modell sieht die VM?

Lösung

lscpu zeigt unter «Virtualization» VT-x oder AMD-V, wenn die verschachtelte Virtualisierung eingeschaltet ist. Unter «Model name» steht das Modell, das der äussere Hypervisor der VM zeigt. Auf smartlearn und unter Hyper-V ist das meist die echte CPU der physischen Maschine.

Aufgabe Einordnen

Die Treuhand Aaregg will ihre Buchhaltungssoftware für Windows betreiben, das Veloatelier seinen Webshop in mehreren Kopien. Wer bekommt eine VM, wer Container? Begründe beide Entscheide.

Lösung

Die Treuhand bekommt eine VM, weil ihre Software ein eigenes Betriebssystem braucht und Container den Kernel des Rechners teilen. Das Veloatelier bekommt Container auf Kubernetes, weil der Webshop schnell startende Kopien braucht, deren Zahl mit der Last wächst und schrumpft.

Texte und Abbildungen stehen unter CC BY-SA 4.0 und der Code unter der MIT-Lizenz. Die Quellen liegen auf GitHub.