Troubleshooting: KVM‑VM bootet nicht mehr — systematische Fehleranalyse und Reparaturbefehle

Wenn eine KVM‑VM plötzlich nicht mehr startet, steht oft mehr auf dem Spiel als ein einmaliger Neustart. In diesem Beitrag zeige ich eine systematische Fehleranalyse und konkrete Reparaturbefehle, damit Administratoren, System Engineers und Operatoren sicher und risikobewusst vorgehen können. Das Fokus‑Keyword „KVM-VM bootet nicht mehr“ wird gleich zu Beginn genannt, denn die hier beschriebenen Prüfschritte gelten sowohl für reine libvirt/QEMU‑Setups als auch für Proxmox und andere KVM‑Hosts.

KVM-VM bootet nicht mehr: Warum eine strukturierte Fehlersuche wichtig ist

Ein ungeplanter Boot‑Failure kann von einem einfachen Konfigurationsfehler bis zu Storage‑Korroption reichen. Ohne strukturierte Herangehensweise drohen Datenverlust oder unnötige Ausfallzeit. In der Praxis zählen schnelle Identifikation, sichere Lesemodi und eine klare Rückfallstrategie.

Überblick: Mögliche Ursachen (auf einen Blick)

• Host‑Dienste gestoppt (z. B. libvirtd, qemu‑kvm)
• Storage‑Probleme: LVM‑Thin voll, NFS/ISCSI verloren, Ceph OSD down
• Disk‑Image beschädigt (qcow2/raw) oder Snapshot‑Inkonsistenz
• Bootloader/EFI/Grub fehlt oder initramfs korrupt
• Netzwerk/Cloud‑Init bootevents, die den Start blockieren
• Hardware/Kernel‑Panik im Gast — keine Konsole konfiguriert

Vorbereitung: Sicher arbeiten und Risiken minimieren

Bevor Sie schreibende Reparaturbefehle ausführen, sollten Sie ein Backup oder zumindest eine Kopie des betroffenen Disk‑Images erstellen. Viele Reparaturtools sind mächtig, aber nicht reversibel. Wenn möglich, arbeiten Sie auf einer Kopie.

Beispiel: Kopie einer qcow2‑Datei anlegen (lokal):

cp -v --reflink=auto vmdisk.qcow2 vmdisk.qcow2.bak

Kommentar: reflink=auto nutzt falls verfügbar CoW auf Dateisystemen wie XFS oder btrfs; ansonsten wird eine normale Kopie erstellt. Bei großen Images ist dies oft schneller und platzsparender. Wenn Sie auf Netzwerk‑Storage arbeiten (NFS/SMB), prüfen Sie vorher freien Platz.

Erste Prüfungen auf dem Host

Beginnen Sie mit Host‑Checks — viele Probleme sind nicht im Gast sondern am Host verursacht.

1) Status der Virtualisierungsdienste

systemctl status libvirtd.service qemu-kvm.service --no-pager

Warum: libvirtd verwaltet VMs via libvirt; wenn der Dienst gestoppt ist oder Fehler in journalctl erscheinen, starten VMs nicht. Bei Proxmox heißt der Dienst pvedaemon bzw. pveproxy — prüfen Sie auch diese.

2) Host‑Logs durchsuchen

journalctl -u libvirtd -n 200
journalctl -k -n 200

Warum: dmesg/journal liefert Hinweise auf Block‑Device‑Fehler, Kernel‑I/O‑Errors oder fehlende Treiber. Wenn der Host I/O‑Errors meldet, ist ein Storage‑Problem wahrscheinlich.

3) Storage‑Layer prüfen

Überprüfen Sie LVM, ZFS, Ceph, NFS oder iSCSI je nach Setup. Beispiele:

# LVM Pools
lvs -a -o +lv_name,lv_attr,lv_size,lv_free
# ZFS Pools
zpool status
# Ceph
ceph -s

Warum: LVM‑Thin kann voll laufen, ZFS‑Pools können degradiert sein, bei Ceph fehlen OSDs. Wenn das Backend nicht verfügbar ist, wird die VM nicht starten oder hängt beim Attach der Disk.

Prüfung der VM‑Konfiguration

Fehler in der VM‑XML (libvirt) oder QCOW‑Snapshot‑Ketten verursachen oft Bootfehler.

1) Domäneninfo und XML ansehen

virsh dominfo vmname
virsh dumpxml vmname > /tmp/vmname.xml

Warum: Dumpxml zeigt Disk‑Pfad, Firmware (BIOS vs. OVMF/UEFI), Console‑Konfiguration und Attached‑Devices. Achten Sie auf falsche Diskpfade, fehlende backing stores bei qcow2 oder auf falsche driver‑type‑Angaben.

2) Device‑Dateipfade prüfen

ls -lh /var/lib/libvirt/images/vm-100-disk-1.qcow2
qemu-img info /var/lib/libvirt/images/vm-100-disk-1.qcow2

Warum: qemu-img info liefert Format (qcow2/raw), virtual size und snapshot‑Kette. Wenn backing file fehlt, qemu kann nicht starten.

Guest‑Konsole aktivieren und Logs lesen

Oft hilft die serielle Konsole, um Boot‑Messages im Gast zu sehen. Die serielle Konsole ist ein einfacher Textzugang zur Kernel/Grub‑Ausgabe.

1) Virsh console nutzen

virsh console vmname
# Bei Bedarf: Escape-Sequenz ~. zum Beenden

Warum: Wenn im Guest eine console ttyS0 eingerichtet ist, sehen Sie kernel‑und initramfs‑Meldungen. Fehlt die Konsole im Gast, funktioniert dieser Weg nicht — dann nutzen Sie das Disk‑Attach‑Verfahren weiter unten.

2) Reihenfolgen von Boot‑Hooks erkennen

Lesen Sie die Meldungen: Hängt es beim Grub, beim initramfs (z. B. busybox Shell) oder weiter im Kernel (Kernel panic)? Jede Phase hat eigene Indikatoren.

Wenn der Disk‑Image verdächtig ist: Diagnostik und sichere Prüfungen

Wenn die VM beim Mounten der Root‑Partition hängt oder initramfs Fehler wirft, prüfen Sie das Disk‑Image auf einem Rescue‑Host.

1) Image auf Integrität prüfen

qemu-img check -r all /var/lib/libvirt/images/vm-disk.qcow2

Warum: qemu-img check analysiert qcow2‑Strukturen. Achtung: Reparaturen sollten erst nach Backup erfolgen. Wenn Fehler gefunden werden, erstellen Sie zuerst eine Kopie des Images.

2) Image schreibgeschützt mounten (guestfish/guestmount)

# Nur lesen, mit libguestfs
guestfish --ro -a /var/lib/libvirt/images/vm-disk.qcow2 -i -- command :
# Alternativ mounten mit libguestfs guestmount
guestmount -a /var/lib/libvirt/images/vm-disk.qcow2 -i /mnt/vmroot --ro

Warum: guestfish / guestmount (libguestfs) erlaubt Zugriff auf Partitionen innerhalb eines VM‑Images ohne Kernel‑Loopmanipulation. So können Sie /etc/fstab, kernel‑cmdline oder cloud‑init Logs prüfen. Verwenden Sie –ro, um das Image nicht versehentlich zu verändern.

3) Loopdev & kpartx verwenden (Alternative)

losetup -f --show /var/lib/libvirt/images/vm-disk.raw
kpartx -av /dev/loopX
mount /dev/mapper/loopXp1 /mnt/vmroot -o ro

Warum: Falls libguestfs nicht verfügbar ist, können Sie das Image konvertieren (qcow2 → raw) und per loop device mounten. Konvertieren kostet Zeit und Platz; arbeiten Sie auf Kopien.

Reparatur im Dateisystem oder Bootloader

Wenn Sie auf die Root‑Partition zugreifen können, sind Reparaturen möglich: fsck, Regeneration von initramfs oder Neuinstallation von GRUB.

1) Filesystem reparieren (immer auf Kopie!)

# Beispiel für ext4 (auf gemounteter oder loopdev ersetztem Device)
e2fsck -f -y /dev/mapper/loopXp1

Warum: e2fsck repariert Dateisystemfehler. -f erzwingt Prüfung, -y beantwortet automatisch mit Ja — verwenden Sie -y nur wenn Sie die Folgen verstehen. Bei XFS verwenden Sie xfs_repair, beachten Sie, dass XFS typischerweise nicht im read‑only repariert werden kann.

2) Initramfs neu erstellen und GRUB wiederherstellen

Falls der Bootloader oder initramfs beschädigt ist, chrooten Sie in das Image und regenerieren Sie:

# Beispielablauf nach Mount der Partitionen
mount --bind /dev /mnt/vmroot/dev
mount --bind /proc /mnt/vmroot/proc
mount --bind /sys /mnt/vmroot/sys
chroot /mnt/vmroot /bin/bash
update-initramfs -u -k all
grub-install --target=i386-pc /dev/sda
update-grub
exit
umount -l /mnt/vmroot/{dev,proc,sys}

Warum: update-initramfs erzeugt die notwendige Initramfs, die beim Kernelboot Laufzeitmodule und Treiber lädt. grub-install/ update-grub schreibt einen funktionierenden Bootloader. Achten Sie bei UEFI‑VMs auf OVMF/EFI‑Konfiguration und verwenden Sie ggf. grub‑install –target=x86_64-efi in einem EFI‑System.

Risiko: chroot und grub-install verändern Disk‑Inhalte. Deshalb vorher Backup erstellen.

Wenn es an Firmware (UEFI / OVMF) liegt

Viele moderne VMs nutzen OVMF (UEFI‑Firmware für QEMU). Wenn OVMF‑Binaries fehlen oder falsch referenziert sind, bootet die VM nicht.

# Prüfen ob OVMF vorhanden ist
ls -l /usr/share/OVMF /usr/share/ovmf /usr/share/qemu/OVMF* /usr/share/ovmf/*
# Beispiel: libvirt XML zeigt 

Warum: Fehlende Dateien oder falsche Berechtigungen verhindern das Laden der Firmware. Prüfen Sie Package‑Upgrades oder Provider‑Änderungen, die OVMF verschoben haben.

Wenn die VM nach Kernel‑Änderung nicht startet

Updates im Gäste‑Kernel oder in initramfs können Rollbacks nötig machen. Wenn Sie Snapshots haben, prüfen Sie die Möglichkeit eines Rollbacks, andernfalls booten Sie in eine Rescue‑Umgebung und wechseln das initrd oder die Kernelversion.

# In chroot: alte Kernelpakete auflisten und ggf. wieder installieren
apt list --installed | grep linux-image
apt install linux-image-
update-grub

Warum: Paket‑Upgrades können inkompatible Treiber/Module liefern. Ein Rollback ist oft die schnellste Lösung, falls zeitnah möglich.

Wenn Netzwerk/Cloud‑Init den Boot blockiert

In Cloud‑Init‑basierten Images kann fehlerhafte Netzwerkkonfiguration den Boot verzögern oder stoppen (z. B. systemd‑timeout beim Anfordern einer DHCP‑Adresse). Prüfen Sie /etc/cloud/cloud.cfg und Netplan/ifupdown Konfigurationen innerhalb des Images.

# Prüfen von cloud-init Logs (via guestmount/guestfish)
cat /var/log/cloud-init.log
cat /var/log/cloud-init-output.log

Warum: Cloud‑Init kann Network‑Waiting verursachen; oft hilft eine Anpassung an eine statische oder tolerantere NetworkManager/Netplan Einstellung.

Wiederanlauf: VM an einer Rescue‑VM anhängen

Wenn Reparaturen im Image notwendig sind, ist das Anfügen der Disk an eine funktionierende Rescue‑VM die sicherste Methode.

# Beispiel libvirt: Disk an Rescue-VM anhängen
virsh attach-disk rescue-vm /var/lib/libvirt/images/vm-disk.qcow2 vdb --driver qemu --subdriver qcow2 --persistent
# Alternative: in Proxmox GUI oder qm set / qm importdisk

Warum: So können Sie in der Rescue‑VM mit bekannten Tools das Dateisystem reparieren oder Logs lesen, ohne die Ziel-VM zu starten.

Wenn alles fehlschlägt: disk snapshot wiederherstellen und Rollback‑Plan

Halten Sie einen Rollback‑Pfad bereit: vorhandene Snapshots, Backups oder Storage‑Replikate. Beschreiben Sie vorab die minimal nötigen Schritte, um eine Service‑Wiederherstellung zu erreichen (z. B. VM an anderem Host starten, Disk aus Replica importieren).

Rollback‑Checkliste

• Gültigen Backup/Snapshot lokalisieren
• Platz und I/O auf Zielhost prüfen
• Disk importieren/restore auf separatem Host testen
• Service‑Tests durchführen (SSH, Anwendungssanity)
• Kommunikation: Downtime, Probleme, Rollback‑Zeitfenster

Typische Stolperfallen und wie man sie vermeidet

• Snapshot‑Ketten: Zu viele qcow2 Snapshots erhöhen Komplexität — konsolidieren Sie vorsichtig.
• Thin‑Provisioning: LVM/ZFS thin kann plötzlich voll laufen — Alerts konfigurieren.
• Inkompatible OVMF‑Versionen nach Host‑Upgrade — prüfen Sie OVMF‑Binaries.
• Fehlende Konsole: Ohne serielle Konsole sind Kernel‑Panik‑Meldungen nicht sichtbar — Konsole dauerhaft konfigurieren.
• Rechtschreibfehler in libvirt XML (Pfad, driver name) — immer dumpxml überprüfen.

Praxisbeispiel: qcow2‑Image hat Backing file missing

Symptom: VM startet nicht, qemu meldet missing backing file.

# Diagnose
qemu-img info vm-disk.qcow2
# Ausgabe zeigt backing file: /var/lib/libvirt/images/base.qcow2 (missing)
# Lösung: ersetzen oder rekreieren backing file
cp /backup/base.qcow2 /var/lib/libvirt/images/
chown libvirt-qemu:kvm /var/lib/libvirt/images/base.qcow2
# Alternativ: rebase um den Backing-Referenzpfad zu entfernen (auf Kopie!)
qemu-img rebase -u -b "" vm-disk.qcow2

Warum: qcow2 kann mit einer backing file arbeiten; fehlt diese, ist das Image inkonsistent. qemu-img rebase entfernt die Verknüpfung zur backing file, das funktioniert nur, wenn die Daten selbstständig korrekt sind — daher vorher Backup.

Monitoring‑ und Präventionshinweise

Um zukünftige Vorfälle zu vermeiden, sollten Sie folgende Punkte in Betrieb nehmen:

• Alerting für Storage‑Fill (LVM/ZFS/Thin/Datastore)
• Regelmäßige Scrubs/Checks (z. B. ZFS scrub, Ceph health checks)
• Automatisierte Test‑Restores in Wartungsintervallen
• Serielle Konsole als Standard in VM‑Templates
• Dokumentierte Recovery‑Runbooks für kritische VMs

Fazit und Prioritätenliste für die Fehleranalyse

Wenn eine KVM‑VM nicht mehr bootet, gehen Sie strukturiert vor: Host‑Dienste, Storage, VM‑Konfiguration, Konsole und Disk‑Integrität. Arbeiten Sie stets auf Kopien, dokumentieren Sie jeden Schritt und stellen Sie eine Rückfalloption bereit. In den meisten Fällen lässt sich der Fehler mit einer Kombination aus Read‑Only‑Analyse (guestmount/guestfish), Filesystem‑Reparatur und ggf. Regeneration von initramfs/GRUB beheben.

Wenn Sie eine schnelle Checkliste wollen, beginnen Sie mit diesen Schritten:

1. Host‑Logs und Dienste prüfen (libvirtd/qemu, dmesg)
2. Storage Backend prüfen (LVM/ZFS/Ceph/NFS)
3. VM XML und Disk‑Pfad kontrollieren
4. Serielle Konsole aktivieren und Logs lesen
5. Image sicher read‑only mounten und Inhalte prüfen
6. Auf Kopie: fsck, initramfs regen und GRUB neu installieren

Dieser Beitrag soll als praktischer Runbook‑Einstieg dienen: technisch präzise, mit konkreten Befehlen und stets mit Blick auf Betriebssicherheit und Recovery‑Strategien.