qemu-Unterstützung

todo: Dynamische Auflösungen?

Zur Verwaltung und Anpassung von QEMU-VMs ist ein Linux-System sehr empfehlenswert. QEMU-Betrieb unter Windows scheint inzwischen zwar einigermaßen möglich zu sein¹⁾, wird von uns jedoch nicht getestet und daher nicht unterstützt.

Einige Distributionen liefern noch relativ alte Versionen von QEMU über ihre Paketquellen aus. Verwenden Sie mindestens Version 5.2.x; eine aktuellere Version (6.x) schadet natürlich nicht.

Installieren Sie von qemu und virt-manager ausgehend die für Ihre Distribution benötigten Pakete, etwa mittels:

sudo apt install qemu qemu-kvm virt-manager       # Ubuntu, Debian
zypper in qemu qemu-kvm virt-manager              # OpenSuse
dnf install qemu qemu-kvm virt-manager            # Red Hat
                                         etc.

Prüfen Sie ggf. nach Abschluß der Installation, ob der libvirtd-Daemon läuft ('systemctl status libvirt-daemon'). Falls nicht automatisch geschehen, sorgt ein 'systemctl enable libvirt-daemon' sorgt für den Start beim Booten; ein 'systemctl start libvirt-daemon' startet ihn manuell.

Der lokal zum Umgang mit qemu/libvirt verwendende User sollte Mitglied der Gruppe libvirt sein. Fügen Sie ihn ggf. dieser Gruppe hinzu.

Unter den jeweiligen Gastsystemen sollten ua. zur Performanzverbesserung folgende Gastprogramme installiert werden:

• virtio Linux-Kernel-Treiber,
• xf86-video-qxl (bei Verwendung der paravirtualisierten 2D QXL-Grafik),
• qemu-ga (qemu-guest-agent),
• spice-vdagent.

• virtio Windows-Treiber per virtio-win-ISO-Installer,
• qemu-ga (qemu-guest-agent),
• spice-vdagent.

Operationen als normaler User ohne weitere connect-Angaben (-c, –connect) und ohne gesetzte LIBVIRT_DEFAULT_URI Umgebungsvariable landen im Kontext qemu:///session. Dabei Achtung auf geringere Berechtigung, z.B. bei Netzwerken. Bei Mitgliedschaft in der Gruppe libvirt daher besser -c qemu:///system benutzen.

Es stehen die folgenden Möglichkeiten zur Verfügung eine neue virtuelle Maschine, bestehend aus einer Maschinenkonfiguration und eines Festplattenabbilds, für ein Gastsystem zu erstellen. Nach der Erstellung erfolgt der Export und Upload der erstellten VM via bwSuite.

Für ein Erstellen einer VM werden folgende Optionen empfohlen:

• emulierte Hardwaregeräte wenn möglich immer auf den Typ virtio stellen
• bevorzugt immer das QCOW2-Format als Format für das Festplattenabbild benutzen, alternativ sind auch VMDK und VDI möglich
• optionale Komprimierung des Festplattenabbilds vor dem Upload vornehmen (siehe Optionale Optimierung der VM)

Ein grafisches Erstellen einer neuen VM erfolgt mittels des Virtual Maschine Managers oder mit Hilfe von Cockpit. Für die Erstellung wird der jeweilige Assistent (Wizard) gestartet und befolgt.

Ein manuelles Erstellen der VM kann alternativ über den folgenden Konsolenaufruf erfolgen.

virt-install --connect qemu:///system \
             --name [VM-Name] \
             --memory [kB] \
             --vcpus [Zahl] \
             --disk [Datei.qcow2],bus=[bus] \
             --os-variant [VM-Betriebssystem] \
             --network [Netz] \
             --check path_in_use=off \
            [--cdrom [iso oder Device]]

Beispiel:

virt-install --connect qemu:///system \
             --name Windows10_x64_Vorlage_Standard \
             --memory 3072 \
             --vcpus 2 \
             --disk Windows10_x64_Vorlage_STANDARD.qcow2,bus=sata \
             --os-variant win10 \
             --network default \
             --check path_in_use=off \
             --cdrom /home/chr/isos/virtio-win-0.1.196.iso

Anmerkung: Mit „osinfo-query os“ (osinfo-query aus libosinfo) können verfügbare Werte für –os-variant angezeigt werden. cdrom-Angabe wertvoll, damit gleich in VM enthalten.

Die Konfiguration der erstellten virtuellen Maschine sollte für einen Upload via bwLehrpool-Suite in einem ersten Schritt mittels des folgenden Konsolenaufrufs exportiert werden. Das Festplattenabbild der VM muss dabei nicht explizit kopiert werden, da die exportierte Konfiguration (XML-Datei) automatisch auf das vorhandene Festplattenabbild verweist.

virsh -c qemu:///system dumpxml [VM-Name] > [xml-Datei]

Hinweis: Folgender Befehl listet die vorhandenen VMs auf, falls Sie sich des VM-Namens nicht sicher sind:

virsh -c qemu:///system list --all

Bevor der Upload via bwLehrpool-Suite vorgenommen wird, kann eine optionale Optimierung des QCOW2 Festplattenabbildes der VM vorgenommen werden. Die Optimierung umfasst das Komprimieren des Festplattenabbilds vor dem Upload der VM, um spätere Bootzeiten der VM zu verringern. Dazu sollten zuvor im Gastsystem alle freien Speicherblöcke mit Nullen beschrieben werden, um die best-möglichste Kompression zu erzielen. Die Kompression des Festplattenabbilds erfolgt mit folgenden Konsolenaufrufen.

mv [Datei.qcow2] [tmp-Datei.qcow2]
qemu-img convert -f qcow2 \
                 -O qcow2 \
                 -c -o compression_type=zstd \
                 [tmp-Datei.qcow2] \
                 [Datei.qcow2]
rm [tmp-Datei.qcow2]

Hinweis: Als Komprimierungsalgorithmus kann zstd (Zstandard) oder zlib verwendet werden. Empfohlen wird der zstd-Algorithmus.

Die exportierte XML-Datei kann in einem nachfolgenden Schritt zum Upload via bwLehrpool-Suite verwendet werden.

Beim Export von Windows VMs in Infrastrukturen wie bwClouds OpenStack gilt der folgende Workflow :

1. VM Disk konvertieren mit qemu-img convert in raw format (Erforderlich Stand 05.22)
2. Es wird empfohlen, VirtIO Treiber zu installieren
3. Je nach Anwendungsfall sind folgende Schritte notwendig:
   a) Cloudinit installieren
   b) und ebenfalls OpenSSH.Server
4. VM Disk als Image ins OpenStack hochladen. (API oder mit Openstack CLI).

Troubleshooting zum Export von Windows Guests:

Wichtig ist es auch, auf die Eigenschaften der Machine zu achten (in OpenStack sog. Properties ). Diese Eigenschaften werden als Metadaten in OpenStack aufgefasst.
Bei der Fehlersuche können die folgenden Properties eine Rolle spielen und sollten auf diese Werte überprüft werden:

hw_cdrom_bus
sata
hw_disk_bus
sata
hw_firmware_type
uefi
hw_machine_type
q35
hw_video_model
vga
hw_vif_model
e1000

Die Optionen cd-rom und disk bus sind wichtig, denn sie erzwingen die Verwendung eines Bustyps, der mit dem von bwLehrpool kommenden vm in der Regel funktioniert.

Der Firmware-Typ hilft bei der Auswahl des richtigen Bootloaders.

Der Maschinentyp wählt einen Chipsatz (entweder i440FX oder Q35), der mit dem Virt-Manager für diese Maschinen funktioniert (in der Regel Q35).

Das Videomodell ist dazu da, um Probleme mit der Standardgrafik von Cirrus zu vermeiden. VGA wurde gewählt, da es das einfachste Anzeigeformat ist.

Schließlich gab es noch Probleme mit der Netzwerkkarte und dem Ethernet-Controller. Um dies zu vermeiden, konnten wir ein virtuelles Netzwerkschnittstellengerät (vif) vom Typ e1000 wählen, das normalerweise auch im virt-manager verwendet wird. Derartige Problemen treten jedoch nur auf, wenn man VirtIO nicht vorher installiert hat.

Eine existierende VM kann für eine Bearbeitung via bwSuite heruntergeladen werden. Vor dem Download sollte geprüft werden, welche Busart zum Ansprechen des Massenspeichers im auf dem Image befindlichen Gastbetriebssystem verwendet wurde (scsi, sata, ata). Ansonsten kann es zu Problemen beim Gast-Boot kommen. Bei Linuxgästen („a start job is running… for dev/disk…“ 1:30) Hibernation kontrollieren (systemd-hibernate-resume), ggf. resume aus KCL entfernen. Nach dem Download der VM erfolgt ein Import der Konfiguration in libvirt mit einem der beiden folgenden Konsolenaufrufen.

virsh -c qemu:///system create [xml-Datei.xml]

virsh -c qemu:///system define [xml-Datei.xml]

• „create“: definiert VM ausgehend von XML-Datei an und startet diese direkt nach Anlage. Entspräche „define“ mit nachfolgendem „start“.
• „define“: führt statische Überprüfungen z.B. Validierung des XMLs aus, startet VM aber nicht. Besser zur Fehlersuche.in QEMU-Prozess erzeugt.

Die Konfiguration der importierten VM kann nun editiert werden und das Gastsystem gestartet werden, wenn noch nicht geschehen. Diese Bearbeitung kann grafisch mittels Virtual Machine Manager oder Cockpit erfolgen.

Mitunter tritt beim Start der VM die Meldung „Requested operation is not valid: network 'default' is not active“ auf. Zur Behebung können Sie entweder das default-Netzwerk starten, oder je nach Ihrer lokalen Umgebung ein anderes (virtuelles) Netzwerk benutzen. Falls Sie ein anderes, lokal definiertes Netzwerk nutzen wollen, importieren Sie die VM mittels „define“, also ohne sie zu starten, und ändern die Einstellung unter (virt-manager) NIC, „Virtuelle Netzwerkschnittstelle“, „Netzwerkquelle“.

Wenn Sie kein anderes virtuelles Netzwerk erzeugt haben oder nutzen wollen, können Sie das default-Netzwerk starten. Sie können mit „virsh net-list“ bestehende Netzwerke auflisten (alle hier beschriebenen virsh-Befehle benötigen root-Rechte bzw. sudo):

virsh net-list --all

 Name      State      Autostart   Persistent
----------------------------------------------
 default   inactive   no         yes

In o. a. Beispiel ist das default-Netzwerk inaktiv. Starten Sie es mit „virsh net-start default“. Wenn wie in obigem Beispiel kein Autostart des default-Netzwerks gegeben ist, können Sie dem mit „virsh net-autostart default“ abhelfen. Eine erneute Abfrage mit net-list sollte dann folgende Ausgabe liefern:

Name      State    Autostart   Persistent
--------------------------------------------
 default   active   yes         yes

Anschließend sollte Ihre VM starten.

Die bearbeitete Maschine wird anschließend wieder exportiert und dann mittels bwSuite gemäß den Instruktionen im Abschnitt Export und Upload der VM als neue Maschinenversion hochgeladen.

CDROM-Wechsel für Gast:

• virsh -c qemu:/system list –all (VMs auflisten), * virsh -c qemu:/system domblklist [VM-Name] (listet Blockdevs a la sda usw.),
• virsh -c qemu:/system change-media [VM-Name] [blockdev] –eject (auswerfen), * virsh -c qemu:/system change-media [VM-Name] [blockdev] [iso-Datei] –insert

• virsh change-media [VM-Name] [blockdev] [iso-Datei] –insert –live (–> Fehler: Die Disk Einheit 'sdb' hat bereits Medien, also immer eject vorher)

„“