KVM

Die in Linux integrierte Virtualisierungslösung heisst KVM (Kernel-based Virtual Machine) und ist seit Version 2.6.20 Bestandteil des Linux-Kernels. KVM ist formal ein Hypervisor vom Typ 2, was bedeutet, dass das Hostsystem (die Maschine, die die virtuellen Maschinen ausführt) im multi-user.target läuft - also selbst ein vollwertiges Linux-Betriebssystem benötigt, um „seine“ Gast-Systeme virtuell ausführen zu können. Es gibt allerdings auch Stimmen, die KVM als Typ 1 klassifizieren.

QEMU (= Quick Emulator) ist ein Hardware-Emulator: es simuliert die komplette Hardware eines Computers in Software und kommt ohne Hardware-Unterstützung aus. Diese Vollvirtualisierung ist entwicklungsintensiv und nicht sonderlich performant.

Das SPICE-Projekt ist eine Open-Source-Lösung für den nahtlosen Fernzugriff auf virtuelle Maschinen.

KVM nutzt vorhandene Hardware, bei welcher es Virtualisierungsunterstützung voraussetzt. Bei dieser „Paravirtualisierung“ (also Virtualisierung, die durch Hardware unterstützt wird) weiss das Gastsystem, dass es in einer virtuellen Umgebung läuft. Es kommuniziert mit speziellen Treibern direkt mit der Hardware des Hostsystems. Die Paravirtualisierung unter KVM nennt sich „VirtIO“. Alternativ nutzt KVM die von QEMU emulierte Hardware.

Ob KVM durch die Hardware unterstützt wird, ermittelt man über die CPU-Eigenschaften. Hardwareseitig wird ein Intel-Prozessor mit Intel VT-x und Intel 64 extensions (im Falle von 64 bit Gastsystemen) oder eine AMD-CPU mit den AMD-V und AMD64 extensions (auch hier, falls man 64 bittige Gast-Betriebssysteme ausführen möchte) benötigt. Das lässt sich auf dem Bare Metal Hypervisor wie folgt kontrollieren:

cat /proc/cpuinfo | grep -E "vmx|svm"

Für erweiterte KVM-Installationen sollte das „No eXecute“-Feature eingeschaltet sein:

cat /proc/cpuinfo | grep -E "nx"

Ein anderer Weg, um die Hardware auf ihre Tauglichkeit hin zu prüfen:

lsmod | grep kvm

Wird hier nichts oder nur „kvm“ statt „kvm“ plus „kvm_intel“ bzw. „kvm_amd“ angezeigt, kann man zwar virtuelle Maschinen installieren und ausführen - allerdings nur QEMU basierend, was einiges an Geduld im Umgang mit den VMs erfordert.

Tipp

Ein produktiver KVM-Host, der eine Reihe an Maschinen hostet, sollte mindestens 16 GB Swap-Space besitzen. Swap-Space wird intensiv verwendet, selbst wenn genügend RAM vorhanden ist.

Grafikkarten:

Karte

VGA compatible

vgabios Support

UEFI Support

Linux Driver

Windows Driver

Recommended On

ATI VGA

Bochs

Desktop + Server with UEFI

Cirrus VGA

QXL

Providing multihead support for windows guests.

Ramfb

Arm

Standard VGA

Desktop, Server

VirtIO GPU

Desktop, ARM

VirtIO VGA

Desktop

Storage:

  • Wer Gluster verwendet, gibt als Storage-Pfad gluster://gluster-host/path/to/vm.qcow2 an.

Links:

KVM installieren - Basics

Ein reiner KVM-Host kommt mit einer Minimal-Installation ohne grafischen Desktop aus, es wird nur das „Virtualization Host“-Package benötigt, welches den Hypervisor sowie die Management-Tools enthält. Wenn es fehlt, installiert man es mit

# RHEL
dnf -y groupinstall "Virtualization Host"

# Fedora
dnf -y install @virtualization
systemctl enable --now libvirtd

Damit wird ein System mindestens zum QEMU- oder - besser - zum KVM/QEMU-Hypervisor, je nach eingesetzter Hardware. Grafisch lässt sich der KVM-Host z.B. entfernt von einer Fedora-Workstation mit VMM managen.

Auch für Windows existiert ein Client, siehe https://virt-manager.org/download/.

Wer seine VMs im UEFI-Mode booten möchte, benötigt noch das OVMF-Paket, welches eine 64-bit UEFI-Firmware für KVM und QEMU enthält:

dnf -y install OVMF

Ist der Host ausschliesslich für die Ausführung von virtuellen Hosts da, kann man folgende Tuning-Anpassung vornehmen:

tuned-adm active
tuned-adm profile virtual-host

KVM installieren - Advanced

Der KVM-Host soll als Router für seine Guests agieren? Wer Gastsysteme betreiben möchte, die logisch gesehen am Netzwerk-Anschluss des KVM-Hosts hängen sollen, muss auf dem KVM-Host eine Bridge auf Basis einer oder mehrerer physischer Netzwerkkarten einrichten, damit der Gast vom Host aus kommunizieren kann. Anschliessend lässt sich im VMM unter „Virtual Networks“ ein Netzwerk auf Basis dieser Bridge im Routed Mode hinzufügen und durch die Gastsysteme nutzen.

Der Trick dann: im VMM kein „Virtual Network“ anlegen - das braucht es nicht, schliesslich sollen die VMs direkt über die Host-Bridge kommunizieren.

Also:

  • auf dem Host eine Bridge anlegen

  • kein „Virtual Network“ im VMM

  • VM erzeugen, IP-Adresse aus dem gebridgden Netz geben

Die Guests müssen NAT auf dem Host verwenden, um sich mit dem echten Netzwerk zu verbinden. Auf dem Host daher:

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/99-ipforward.conf
sysctl -p

In der physischen Netzwerkkarte des Hosts alle IP-Eigenschaften deaktivieren, und die Bridge-Angabe hinzufügen. Beispiel:

/etc/sysconfig/network-scripts/ifcfg-eno16777736
#DNS1="192.168.202.2"
#GATEWAY="192.168.202.2"
#IPADDR="192.168.202.111"
#NETMASK="255.255.255.0"
BRIDGE=virbr0
DEVICE="eno16777736"
HWADDR="00:0c:29:32:d0:4c"
ONBOOT=yes

Bridge erstellen:

/etc/sysconfig/network-scripts/ifcfg-virbr0
BOOTPROTO=static
DEVICE=virbr0
DNS1=192.168.202.2
GATEWAY=192.168.202.2
IPADDR=192.168.202.111
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=BRIDGE

Reboot.

VMM

Virtuelle Maschinen administriert man am bequemsten grafisch - mit dem „Virtual Machine Manager“ (VMM). Dieser muss nicht zwangsläufig auf dem Hypervisor installiert werden; man kann ihn auch lokal installieren und sich zur Administration mit dem KVM-Hypervisor verbinden:

dnf -y install virt-manager

virsh Cheat Sheet

Das Kommandozeilen-Tool virsh verwaltet VMs und den KVM-Hypervisor. Wird es ohne Parameter aufgerufen, öffnet sich die interaktive virsh-Shell. Mit „Domain“ ist der Name einer virtuellen Maschine gemeint. So wird es installiert:

dnf -y install libvirt-client

virsh COMMAND DOMAIN-ID [OPTIONS]

virsh help
virsh help restore

virsh capabilities
virsh list --all

virsh autostart my_vm
virsh start my_vm
virsh suspend my_vm
virsh resume my_vm
virsh reboot my_vm
virsh shutdown my_vm

virsh edit my_vm
virsh destroy my_vm

virsh blkiotune my_vm
virsh memtune my_vm --hard-limit 1g
virsh setmem my_vm 2048m
virsh schedinfo my_vm cpu_shares=100
virsh vcpupin my_vm 0 1,3

virsh net-list --all
virsh net-define ./bridge.xml
virsh net-start br0
virsh net-autostart br0

# get all IP addresses
# assuming, "default" is the name of the network
virsh -r net-dhcp-leases default

virsh pool-define /tmp/gluster-storage.xml
virsh pool-start glusterfs-pool
virsh pool-list --all virsh vol-list glusterfs-pool

virsh create my_vm.xml
virsh define my_vm.xml
virsh dumpxml my_vm > my_vm.xml
virsh save my_vm my_vm.xml
virsh restore my_vm.xml

virsh domdisplay --domain my_vm
# with Remote-viewer installed
remote-viewer $OUTPUTOFPREVIOUSCOMMAND

Die Auslastung des Hypervisors ermittelt man mit virt-top.

Ablage ISO-Images

ISO-Images für die zu installierenden Gast-Betriebssysteme kann man erst einmal hier ablegen:

cd /var/lib/libvirt/images
wget http://mirror.switch.ch/ftp/mirror/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1503-01.iso

KVM/VirtIO Guest Tools für Windows

Die aktuellsten VirtIO-Driver für Windows können hier im ISO- und RPM-Format bezogen werden: https://github.com/virtio-win/virtio-win-pkg-scripts/blob/master/README.md. Mehr Informationen finden sich hier https://fedoraproject.org/wiki/Windows_Virtio_Drivers

OVA-Appliance in KVM importieren

Das OVA-Format ist nichts anderes als ein tar-Archiv, welches die VM-Konfiguration in Form einer Open Virtualization Format-Datei (.ovf) und deren Festplatten als Virtual Machine Disk-Dateien (.vmdk) enthält. Es lässt sich nicht direkt in KVM importieren, daher geht man wie folgt vor:

tar xvf appliance.ova
rm -f appliance.ova

Schauen, welche Disk-Formate unterstützt werden (gewünscht wäre „qcow2“):

qemu-img -h | tail -n1

Umwandeln der vmdk-Dateien in das qcow2-Format, die in der Regel damit grösser werden:

qemu-img convert -O qcow2 appliance-disk1.vmdk appliance-disk1.qcow2
rm -f appliance-disk1.vmdk

Nach der Konvertierung der Disk(s) erzeugt man mit den Vorgaben aus der OVF-Datei manuell eine neue VM und hängt die erzeugte(n) .vmdk-Datei(en) ein.

Image-Datei verkleinern/shrinken (ohne Kompression):

qemu-img convert -O qcow2 image.qcow2 shrinked-image.qcow2

Nested Virtualization

Vorher prüfen:

  • Das Betriebssystem muss Nested Virtualization unterstützen: cat /sys/module/kvm_intel/parameters/nested (# => N = No, Y = Yes)

  • Kann die VM Virtualisierung bieten? In der VM: cat /proc/cpuinfo \| grep -E "vmx|svm"

So wird es auf Intel aktiviert:

  • Alle VMs herunterfahren.

  • Unload kvm_probe module: modprobe -r kvm_intel

  • Nesting-Feature zur Laufzeit aktivieren: modprobe kvm_intel nested=1

  • Dauerhaft einrichten: echo "options kvm_intel nested=1" >> /etc/modprobe.d/kvm.conf

  • CPU-Passthrough einrichten: Im KVM in der VM bei der CPU von Hand „host-passthrough“ eintippen.

Siehe auch https://fedoraproject.org/wiki/How_to_enable_nested_virtualization_in_KVM

Shutdown KVM

Wird der KVM-Host heruntergefahren, werden die Gastsysteme in der Standardeinstellung „suspended“. Sollen die Gastsysteme runterfahren, wenn der Host runtergefahren wird, ist folgendes anzupassen:

dnf -y install libvirt-client
/etc/sysconfig/libvirt-guests
ON_SHUTDOWN=shutdown
SHUTDOWN_TIMEOUT=20
systemctl enable libvirt-guests

Service aktivieren, jedoch nie auf einem Host, der gerade VMs ausführt. Damit werden alle VMs heruntergefahren:

systemctl start libvirt-guests

Troubleshooting

qemu: could not open disk image …: Permission denied
chmod 0660 auf-das-diskimage

Built on 2022-06-03