Einführung
Die Verwaltung virtueller Maschinen umfasst mehr als nur das Erstellen und Starten einer Domain. Häufig übernehmen Administratoren eine bereits vorhandene VM und müssen deren persistente Ressourcendefinition ändern: den Arbeitsspeicher vergrößern, zusätzliche virtuelle CPUs bereitstellen, Speicher anschließen, den automatischen Start aktivieren und nachweisen, dass der laufende Zustand der gewünschten Konfiguration entspricht.
In der libvirt-Terminologie wird eine virtuelle Maschine als Domain bezeichnet. Eine persistente Domain verfügt über eine gespeicherte Definition – sinngemäß ihren Hardware-Bauplan –, auch wenn kein QEMU-Prozess läuft. Beim Starten der Domain wird anhand dieser Definition eine laufende Instanz erstellt. Beim Anhalten wird die laufende Instanz entfernt, der Bauplan bleibt jedoch erhalten. Die Trennung zwischen persistenter Konfiguration und Laufzeitstatus ist das zentrale Konzept dieses Labs.
In diesem Lab ist bereits eine ausgeschaltete libvirt-Domain namens lfcs-config definiert. Sie verfügt über eine kleine Boot-Festplatte, 64 MiB Arbeitsspeicher und eine vCPU. Sie überprüfen zunächst diesen Ausgangszustand und konfigurieren die Domain anschließend mit den Ressourcenverwaltungsbefehlen von virsh neu. Die Umgebung stellt /dev/kvm nicht bereit, daher verwendet QEMU Softwareemulation. Die Festplatten enthalten außerdem kein Gastbetriebssystem. Der Verwaltungsablauf und die persistente libvirt-Konfiguration sind dennoch real.
Vorhandene Domain-Konfiguration überprüfen
In diesem Schritt ermitteln Sie die persistente Konfiguration und den Laufzeitstatus der vorhandenen Domain lfcs-config, bevor Sie Änderungen vornehmen.
Wechseln Sie in das Projektverzeichnis.
cd /home/labex/project
Listen Sie alle Domains auf. Die Option --all schließt angehaltene Domains ein, daher sollte lfcs-config im Zustand shut off angezeigt werden.
sudo virsh list --all
Ohne --all zeigt virsh list normalerweise nur aktive Domains an. Wenn in der erweiterten Liste eine angehaltene Domain erscheint, bestätigt dies, dass libvirt ihre persistente Definition weiterhin kennt, obwohl die VM als laufender Gast keine CPU-Zeit verbraucht.
Zeigen Sie eine Zusammenfassung der Domain an.
sudo virsh dominfo lfcs-config
dominfo fasst Identität, Lebenszyklus, CPU, Arbeitsspeicher, Persistenz und automatischen Start zusammen. Betrachten Sie diese Ausgabe zunächst als Ausgangsbasis und nicht als Ziel: Spätere Ausgaben sollten sich nur in den Feldern ändern, die Sie bewusst neu konfigurieren.
Konzentrieren Sie sich auf die stabilen Konfigurationsfelder:
Name: lfcs-config
State: shut off
CPU(s): 1
Max memory: 65536 KiB
Used memory: 65536 KiB
Persistent: yes
Autostart: disable
Libvirt gibt den Arbeitsspeicher hier in KiB aus. Da 1 MiB 1024 KiB entspricht, sind 65536 KiB gleich 64 MiB. Persistent: yes bedeutet, dass die Definition auch nach dem Herunterfahren erhalten bleibt. Autostart: disable bedeutet, dass libvirt diese Domain beim Start seines Virtualisierungsdienstes nicht automatisch startet.
Listen Sie die angeschlossenen Blockgeräte auf. vda ist die vorbereitete Root-Festplatte; als Quelle dient das vorhandene qcow2-Abbild.
sudo virsh domblklist lfcs-config --details
In dieser Tabelle bezeichnet Target den Gerätenamen, unter dem das Gerät im Gast erscheint. Source ist der Pfad auf dem Host, an dem die Daten gespeichert werden. Die virtio-Festplatte vda entspricht einem virtuellen Laufwerk, das an die VM angeschlossen ist; die qcow2-Quelldatei ist das zugehörige Abbild auf dem Host.
Diese Ausgangsanalyse trennt die bereits vorhandenen Komponenten von den Ressourcenänderungen, die Sie in den folgenden Schritten vornehmen.
Persistenten Arbeitsspeicher und vCPUs konfigurieren
In diesem Schritt erhöhen Sie den persistenten maximalen Arbeitsspeicher, die beim nächsten Start zugewiesene Speichermenge und die Anzahl der vCPUs, während die Domain ausgeschaltet ist.
Libvirt unterscheidet zwischen der maximalen Speichergrenze und der Speichermenge, die beim nächsten Start zugewiesen wird. Setzen Sie zunächst den persistenten Höchstwert auf 128 MiB. Die Option --config ändert die gespeicherte Domain-Definition und nicht einen vorübergehenden Laufzeitwert.
sudo virsh setmaxmem lfcs-config 128M --config
Die Obergrenze muss groß genug sein, um die zugewiesene Speichermenge aufzunehmen. Stellen Sie sich max memory als die Speicherkapazität der virtuellen Maschine und current memory als die für den normalen Betrieb angeforderte Menge vor. Da die Domain ausgeschaltet ist, ist eine Änderung mit --config eindeutig und wird beim nächsten Start wirksam.
Setzen Sie die beim nächsten Start zugewiesene Speichermenge auf 96 MiB.
sudo virsh setmem lfcs-config 96M --config
Das Suffix M weist virsh an, den Wert in Mebibyte zu interpretieren. Die spätere Ausgabe von dominfo rechnet 128 MiB in 131072 KiB und 96 MiB in 98304 KiB um. Es handelt sich dabei um dieselben Mengen in unterschiedlichen Einheiten.
Bevor die aktuelle persistente Zuweisung zwei CPUs verwenden kann, muss zunächst die maximale Anzahl der vCPUs erhöht werden.
sudo virsh setvcpus lfcs-config 2 --config --maximum
Dieser erste CPU-Befehl ändert die Obergrenze in der gespeicherten Definition. Dadurch werden nicht automatisch zwei nutzbare vCPUs zugewiesen. Die Trennung zwischen Maximum und aktueller Zuweisung ermöglicht es einer VM-Definition, Kapazitäten für eine spätere Skalierung vorzuhalten.
Setzen Sie zwei vCPUs für den nächsten Start.
sudo virsh setvcpus lfcs-config 2 --config
Der zweite Befehl legt die persistente Zuweisung innerhalb der neuen Obergrenze fest. Die Reihenfolge ist wichtig: Eine Anforderung von zwei zugewiesenen vCPUs würde fehlschlagen, solange das Maximum noch bei eins liegt.
Überprüfen Sie die aktualisierte persistente Definition.
sudo virsh dominfo lfcs-config
Die relevanten Felder sollten nun folgende Werte anzeigen:
CPU(s): 2
Max memory: 131072 KiB
Used memory: 98304 KiB
Persistente Datenfestplatte erstellen und anschließen
In diesem Schritt erstellen Sie ein zweites qcow2-Abbild und schließen es als persistente virtio-Festplatte mit dem Namen vdb an.
Erstellen Sie im Abbildverzeichnis von libvirt ein dynamisch belegtes qcow2-Abbild mit einer Größe von 64 MiB.
sudo qemu-img create -f qcow2 /var/lib/libvirt/images/lfcs-config-data.qcow2 64M
Der Befehl erstellt einen Container für eine virtuelle Festplatte, kein Dateisystem und kein eingehängtes Verzeichnis. -f qcow2 wählt das Copy-on-Write-Abbildformat von QEMU aus, während 64M die virtuelle Kapazität festlegt. Ein neu erstelltes, dynamisch belegtes Abbild beansprucht zunächst deutlich weniger Host-Speicher als seine virtuelle Größe und wächst, sobald der Gast Daten schreibt.
Erlauben Sie dem QEMU-Prozess in dieser Schulungsumgebung, das temporäre Abbild zu öffnen.
sudo chmod 666 /var/lib/libvirt/images/lfcs-config-data.qcow2
Der Modus 666 gewährt allen Benutzerklassen Lese- und Schreibrechte. Diese weitreichende Berechtigung macht das temporäre Lab unabhängig von hostspezifischen QEMU-Benutzern und -Gruppen. Sie ist jedoch keine Empfehlung für Produktionsumgebungen. Verwenden Sie auf einem echten Host stattdessen die für den lokalen libvirt-Dienst erforderlichen Eigentümer, Gruppen, SELinux-Labels oder AppArmor-Richtlinien.
Schließen Sie die Datei an lfcs-config an. Die Option --target vdb benennt das Blockgerät im Gast, --subdriver qcow2 speichert das Abbildformat, und --config ändert die persistente Definition für den nächsten Start.
sudo virsh attach-disk lfcs-config \
/var/lib/libvirt/images/lfcs-config-data.qcow2 \
vdb --targetbus virtio --subdriver qcow2 --config
Der Quellpfad gehört zum Host; vdb ist der Name, unter dem das Gerät im Gast sichtbar wäre. --targetbus virtio wählt eine paravirtualisierte Festplattenschnittstelle aus, die häufig für effiziente Linux-Gäste verwendet wird. Da die Domain ausgeschaltet ist und der Befehl --config verwendet, speichert libvirt das Gerät im gesicherten Bauplan, anstatt einen Live-Hot-Plug zu versuchen.
Listen Sie die persistente Blockgerätekonfiguration auf.
sudo virsh domblklist lfcs-config --details
Die Ausgabe sollte nun sowohl vda als auch vdb enthalten, wobei vdb auf lfcs-config-data.qcow2 verweist.
An diesem Punkt handelt es sich beim Abbild und der Zuordnung zur Domain um zwei getrennte Sachverhalte. Das alleinige Erstellen einer qcow2-Datei verbindet sie nicht mit einer VM. Ebenso löscht das spätere Trennen einer Festplatte ihre Quelldatei nicht automatisch.
Automatischen Start aktivieren und Laufzeitstatus überprüfen
In diesem Schritt aktivieren Sie den automatischen Start der Domain, starten die VM sofort und vergleichen ihre Laufzeitressourcen mit den persistenten Einstellungen.
Aktivieren Sie den automatischen Start, damit libvirt diese Domain beim Start des Virtualisierungsdienstes automatisch startet.
sudo virsh autostart lfcs-config
Der automatische Start ist ein gespeichertes Richtlinienmerkmal und keine Aufforderung, die Domain sofort zu starten. Er ist nützlich für Infrastrukturdienste, die nach einem Neustart des Hosts oder des libvirt-Dienstes automatisch wieder verfügbar sein sollen.
Starten Sie die Domain mit ihrer aktualisierten persistenten Definition.
sudo virsh start lfcs-config
Beim Start wird anhand der gespeicherten Definition, die Sie bearbeitet haben, ein QEMU-Prozess mit zwei vCPUs, den neuen Speichergrenzen und beiden Festplatten erstellt. Der Befehl meldet lediglich, dass die Domain gestartet wurde. Mit dominfo und domblklist können Sie nachweisen, dass ihr Zustand der gewünschten Konfiguration entspricht.
Geben Sie QEMU einige Sekunden Zeit, in den laufenden Zustand zu wechseln.
sleep 3
Überprüfen Sie die Domain. Sie sollte mit zwei vCPUs, maximal 128 MiB Arbeitsspeicher und aktiviertem automatischem Start laufen.
sudo virsh dominfo lfcs-config
Bei dieser softwareemulierten Domain beträgt das laufende Feld Used memory normalerweise 128 MiB, obwohl die persistente Anforderung currentMemory bei 96 MiB liegt. Da kein Gastbetriebssystem und kein Balloon-Treiber mit libvirt zusammenarbeiten, kann die Laufzeitzuweisung nicht reduziert werden. Überprüfen Sie die inaktive XML-Definition, um zu bestätigen, dass die Konfiguration für den nächsten Start weiterhin 96 MiB enthält:
sudo virsh dumpxml lfcs-config --inactive | grep -E '<memory|<currentMemory|<vcpu'
dumpxml --inactive fordert die gespeicherte Definition an und nicht die laufende Ansicht von QEMU. Die Pipe übergibt diese XML-Ausgabe an grep, das nur die Speicher- und CPU-Elemente anzeigt. Dieser gezielte Vergleich verhindert, dass ein erwarteter Unterschied bei der Laufzeitanzeige fälschlicherweise als fehlgeschlagene Konfigurationsänderung interpretiert wird.
Zu den stabilen Werten gehören <memory unit='KiB'>131072</memory>, <currentMemory unit='KiB'>98304</currentMemory> und ein vCPU-Wert von 2. Dieser Vergleich verdeutlicht, warum persistente Konfiguration und Laufzeitressourcen getrennt überprüft werden sollten.
Listen Sie die Festplatten der aktiven Domain auf.
sudo virsh domblklist lfcs-config --details
Sowohl vda als auch vdb sollten erscheinen. Damit wird nachgewiesen, dass die gespeicherte Konfiguration beim Start von QEMU angewendet wurde.
VM anhalten und persistenten Zustand bestätigen
In diesem Schritt stoppen Sie den Gastprozess, während die konfigurierte Domain, der Speicher und die Einstellung für den automatischen Start erhalten bleiben.
Da die Schulungsfestplatten kein Betriebssystem enthalten, kann ein ordnungsgemäßes Herunterfahren des Gasts nicht abgeschlossen werden. Verwenden Sie destroy, um den QEMU-Prozess sofort zu stoppen. Dadurch ändert sich nur der Laufzeitstatus; die persistente Domain-Definition wird nicht gelöscht.
sudo virsh destroy lfcs-config
Trotz seines Namens entspricht virsh destroy eher dem Abschalten der Stromversorgung als dem Löschen einer VM. Der Befehl ist hier nur deshalb geeignet, weil die Übung weder ein Gastbetriebssystem noch wertvolle Daten enthält. Bei einem realen laufenden Gast sollten Sie virsh shutdown bevorzugen und dem Betriebssystem ermöglichen, Daten zu schreiben und sich ordnungsgemäß zu beenden.
Bestätigen Sie, dass die Domain angehalten wurde.
sudo virsh domstate lfcs-config
Die Ausgabe sollte lauten:
shut off
Überprüfen Sie abschließend die persistente Konfiguration.
sudo virsh dominfo lfcs-config
Der erwartete Zustand shut off beschreibt ausschließlich den Laufzeitstatus. CPU, Arbeitsspeicher, Festplattenzuordnungen und automatischer Start bleiben in der persistenten Definition erhalten. Das Entfernen dieser Definition würde einen anderen Vorgang erfordern, beispielsweise virsh undefine. Auch das Aufheben der Domain-Definition löscht ihre Festplattenabbilder nicht zwangsläufig.
Listen Sie alle Domains und deren Einstellung für den automatischen Start auf. Die angehaltene Domain lfcs-config sollte weiterhin definiert und für den automatischen Start markiert sein.
sudo virsh list --all --autostart
Die VM ist nun angehalten, kann aber später mit der von Ihnen erstellten Ressourcenkonfiguration wieder gestartet werden.
Zusammenfassung
Sie haben eine bestehende libvirt-Domain übernommen und ihre persistente Ressourcenkonfiguration geändert, ohne ihre XML-Definition vollständig neu zu schreiben. Sie haben den maximalen und den zugewiesenen Arbeitsspeicher erhöht, zwei vCPUs konfiguriert, eine zweite qcow2-Festplatte erstellt und angeschlossen, den automatischen Start aktiviert, die Konfiguration in einer laufenden QEMU-Domain überprüft und den Prozess anschließend gestoppt, ohne die verwaltete VM zu entfernen. Das ist der praktische Unterschied zwischen dem bloßen Erkunden des Lebenszyklus einer VM und dem Konfigurieren einer VM auf einen vorgegebenen Zielzustand.
