Virtualisierung

libvirt

libvirt ist eine herstellerneutrale Management-Schicht für Virtualisierung: API, Daemon und virsh steuern VMs, Netze und Speicher hypervisorübergreifend.

Beratung anfragen Einsatz prüfen lassen
  • Offene Management-API (LGPL)
  • Hypervisor-Abstraktion
  • Domains, Netze, Storage Pools
  • virsh, virt-manager, Cockpit
  • sVirt, polkit, TLS/SASL
Von Andreas Huser, Technische Beratung & Architektur Aktualisiert am 11 Min. Lesezeit

libvirt ist kein Hypervisor, sondern die Verwaltungsschicht darüber. Es stellt eine stabile Programmierschnittstelle bereit, die einen Hypervisor wie KVM/QEMU einheitlich ansprechbar macht: VMs anlegen, Netzwerke und Speicher verwalten, Migrationen anstoßen. Anwendungen müssen sich so nicht um die wechselnden Schnittstellen der einzelnen Hypervisoren kümmern.

Dieser Artikel erklärt das Treiber-Modell und die unterstützten Hypervisoren, den Wechsel vom monolithischen libvirtd zu den modularen Daemons, das XML-basierte Objektmodell, die Storage- und Netzwerkoptionen, den abgesicherten Remote-Zugriff und die Einordnung von libvirt als Unterbau großer Plattformen wie OLVM, OpenStack und KubeVirt.

1. Eine API für viele Hypervisoren

libvirt schiebt sich als stabile Schicht zwischen Verwaltungswerkzeuge und den jeweiligen Hypervisor. Über austauschbare Treiber spricht es nicht nur QEMU/KVM an, sondern auch Xen, LXC, Bhyve, VMware ESX, Hyper-V und weitere. Der Funktionsumfang ist je Treiber unterschiedlich: Für QEMU/KVM ist er am vollständigsten (Snapshots, Live-Migration, Storage, Netzwerk), für ESX oder Hyper-V deutlich eingeschränkter.

Der Gewinn liegt in der Konstanz: Dieselben Werkzeuge und dieselben XML-Definitionen funktionieren unabhängig davon, was darunter läuft. Ein Wechsel des Hypervisors ändert nicht die Management-Codebasis.

2. Vom Monolithen zu modularen Daemons

Historisch steuerte ein einziger Daemon, libvirtd, alle Treiber. Ein Fehler in einem Bereich konnte alle anderen beeinträchtigen. Die moderne Architektur teilt das auf eigenständige Daemons auf, je einen pro Aufgabe: virtqemud für QEMU/KVM, dazu virtnetworkd, virtstoraged, virtnodedevd, virtsecretd und weitere.

Der Vorteil ist handfest: Ein Neustart von virtstoraged berührt laufende VMs nicht, und ein Problem in einem Daemon reißt nicht den Rest mit. Bei Neuinstallationen neuerer Distributionen (etwa RHEL 9, aktuelle Fedora) sind die modularen Daemons Standard, bei älteren (RHEL 8) das monolithische libvirtd; ein Upgrade von RHEL 8 wechselt nicht automatisch.

3. Das Objektmodell und XML

libvirt beschreibt alles als Objekte, die als XML definiert und gespeichert werden:

  • Domain die virtuelle Maschine, identifiziert über Name, Laufzeit-ID und UUID; das XML enthält CPU, Speicher, Geräte und Boot-Parameter.
  • Network ein virtuelles Netzwerk (NAT, geroutet, Bridge, Open vSwitch, isoliert).
  • Storage Pool und Volume ein Speicherbereich (Verzeichnis, LVM, iSCSI, Ceph/RBD, NFS) und die einzelnen Datenträger darin.
  • Node Device, Secret, Interface physische Geräte für Passthrough, verschlüsselte Zugangsdaten und Host-Netzwerkschnittstellen.

Alltag mit virsh

virsh list --all            # alle Domains anzeigen
virsh dumpxml web01         # Definition als XML ausgeben
virsh start web01           # VM starten
virsh migrate --live web01 qemu+ssh://host2/system
virsh pool-list             # Storage Pools anzeigen

4. Storage und Netzwerk

Als Storage-Backends unterstützt libvirt unter anderem Verzeichnisse mit Image-Dateien, LVM, iSCSI, Ceph/RBD, NFS und ZFS, jeweils als Pool, aus dem Volumes entstehen. Auf der Netzwerkseite kennt es NAT für einfache Host-Anbindung, geroutete und Bridge-Modi für direkten Layer-2-Zugang, die Integration in Open vSwitch sowie isolierte Netze und die direkte Zuweisung von SR-IOV-Funktionen. Der Admin richtet das Backend einmal als Pool oder Netzwerk ein, danach verwalten die Werkzeuge die einzelnen VMs darauf.

5. Remote-Zugriff und Zugriffsrechte

libvirt-Clients sprechen einen Host über eine URI an, lokal qemu:///system, entfernt etwa qemu+ssh://user@host/system oder TLS-gesichert qemu+tls://host/system. Der unverschlüsselte TCP-Transport gehört nicht in Produktion.

Den Zugriff steuern drei Mechanismen: die Berechtigungen des Unix-Sockets (Mitgliedschaft in der Gruppe libvirt entspricht praktisch Root auf dem Hypervisor), feingranulare polkit-Regeln für rootlose Delegation und SASL für Passwort- oder Kerberos-Authentifizierung über das Netz.

6. Isolation per sVirt

libvirt verbindet die VMs automatisch mit dem Sicherheitsstack des Hosts. Über sVirt bekommt jeder QEMU-Prozess ein eigenes SELinux- oder AppArmor-Label, und die zugehörigen Disk-Images werden passend etikettiert. Selbst ein erfolgreicher Ausbruch aus einer VM kann so nicht auf die Images anderer VMs oder den Host zugreifen. Das Besondere: libvirt setzt diese Labels selbst, der Admin muss SELinux nicht von Hand konfigurieren.

7. Unterbau großer Plattformen

libvirt ist selten das, womit Endanwender direkt arbeiten, aber fast überall darunter:

Plattform / WerkzeugRolle von libvirt
oVirt / OLVMder Host-Agent steuert KVM über die libvirt-API
OpenStack Novader meistgenutzte Compute-Treiber spricht libvirt an
KubeVirtstartet QEMU je VM über libvirt in Kubernetes-Pods
virt-manager / Cockpitgrafische bzw. webbasierte Oberfläche auf libvirt

8. Stärken und Grenzen

StärkenGrenzen
Einheitliche, stabile API über viele HypervisorenReines Single-Node-Management, kein Cluster
Breite Sprach-Bindings, Hypervisor-Wechsel ohne Code-UmbauFunktionsumfang je Treiber sehr unterschiedlich
Modulare Daemons erhöhen FehlertoleranzXML ist mächtig, aber komplex zu debuggen
Tiefe Integration in SELinux/AppArmor (sVirt) und polkitkein Scheduler: libvirt entscheidet nicht, wo eine VM läuft
De-facto-Standard und Unterbau aller großen PlattformenUmstieg libvirtd zu modularen Daemons erfordert Planung

Häufige Fragen zu libvirt

Nein. libvirt ist eine Management-Schicht über dem Hypervisor. Es führt selbst keine VMs aus, sondern steuert einen darunterliegenden Hypervisor wie KVM/QEMU oder Xen über eine einheitliche API. Die eigentliche Virtualisierung leistet der Hypervisor; libvirt macht ihn bequem und herstellerneutral bedienbar.

libvirtd ist der klassische, monolithische Daemon, der alle Treiber in einem Prozess vereint. virtqemud ist einer der modernen modularen Daemons, der nur QEMU/KVM betreut, ergänzt um eigene Daemons für Netzwerk, Storage und mehr. Die modulare Variante ist robuster, weil ein Neustart oder Fehler eines Daemons die anderen nicht beeinträchtigt.

Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.

Der nächste Schritt

libvirt im eigenen Haus richtig einsetzen?

Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.

Erstgespräch vereinbaren oder Formular ausfüllen