Proxmox-VM-Festplatten mit fsck reparieren

Ein fsck (File System Check) wird notwendig, wenn das Dateisystem inkonsistent oder beschädigt ist – typischerweise nach einem unsauberen Shutdown, plötzlichem Stromausfall oder Kernel-/I/O-Fehlern. Das kann man klassisch mit einem Live-System wie GParted Live machen, den man als ISO-Image auf dem Proxmox-Host zur Verfügung stellt und den einzelnen VMs am CD-Laufwerk einhängt. Das geht sowohl über die Promox-GUI als auch im Bash-Terminal.

Hier soll jetzt aber der File System Check über die Bash-Konsole auf dem Proxmox-Host vorgestellt werden. Es wird zudem angenommen, dass die VM-Images auf einem ZFS-basierten Storage, wie bei Promox defaultmässig üblich, liegen. 
Der Gedanke ist folgender:
Die Festplatte und ihre Partitionen liegen ja innerhalb des ISO-Images der VM auf dem ZFS-Volume. Dann könnte man doch direkt vom KVM-Host aus den fsck-Befehl auf die Systemplatte der VM absetzen. So einfach ist das jedoch nicht, da es sich hier um ein komplettes virtuelles Laufwerk, also eine virtuelle Festplatte mit Partitionstabelle (z. B. MBR oder GPT) handelt. Diese enthält eine Partitionstabelle und typischerweise eine oder mehrere Partitionen, z.B./dev/zvol/zp_100/vm-100-disk-0 enthält sda1, sda2 etc. Wenn also einfach 

~# fsck /dev/zvol/zp_100/vm-100-disk-0

durchgeführt würde, wird nicht das eigentliche Dateisystem geprüft, sondern die Rohdatei inklusive der Partitionstabelle - was nicht korrekt ist und zu Datenverlust führen kann.

Also wird für diese Vorgehensweise zuerst das Programm kpartx installiert.

~# apt-get update
~# apt install -y kpartx

Hauptfunktion von kpartx

Dabei handelt es sich um ein Linux-Kommandozeilenwerkzeug, das verwendet wird, um Partitionstabellen in Abbilddateien oder Gerätedateien zu analysieren und die darin enthaltenen Partitionen im System verfügbar zu machen – also Mapper-Geräte für Partitionen zu erstellen. Dadurch werden z. B. Geräte wie /dev/mapper/loop0p1, /dev/mapper/loop0p2 usw. erstellt, die wie normale Partitionen gemountet werden können.

Vorgehensweise des File System-Checks mit kpartx

Zunächst wird die ID der VM benötigt, die man auf diesem Weg ermitteln kann.

~# qm list
        VMID NAME                          STATUS       MEM(MB)   BOOTDISK(GB) PID
        100 DNS-Master-Server     running     3072             150.00               1626922
        101 Secondary-DNS-Server running   3072             150.00               1358521

Zusätzlich muss die zu behandelnde VM 100 gestoppt werden:

~# qm stop 100

Anschließend wird der Speicherort der Festplatte benötigt, der sich mit “scsi0:” aus

~# qm config 100

herleiten lässt. Damit ersichtlich wo die Festplatte liegt und wie sie heißt:

scsi0: zp_100:vm-100-disk-0,cache=writethrough,iothread=1,size=150G

Respektive 

~# ls -l /dev/zvol/zp_100/vm-100-disk-0
lrwxrwxrwx 1 root root 10 Jun 11 12:27 /dev/zvol/zp_100/vm-100-disk-0 -> ../../zd16

Jetzt kann kpartx angewendet werden - vorausgesetzt 

~# qm status 100

liefert “stopped”. Mit

~# kpartx -av /dev/zd160

werden die Partitionen gemappt, die sich mit

~# blkid /dev/mapper/zd160p1

anzeigen lassen. Jetzt kann der File System Check auf die einzelnen Partitionen durchgeführt werden.

~# fsck -y /dev/mapper/zd160p1
~# fsck -y /dev/mapper/zd160p2
~# fsck -y /dev/mapper/zd160p5

Danach muss das Mapping wieder rückgängig gemacht werden.

~# kpartx -dv /dev/zd160

Und die VM kann wieder gestartet werden

~# qm start 100
~# qm status 100

Auf der VM 100 auf der Bash-Konsole eingeloggt wird jetzt noch der Test

~# dumpe2fs -h /dev/sda1 | grep ‘Error count’

abgesetzt. Es sollte keine Fehlerzahl mehr auftreten, wenn alles gut gelaufen ist. Dann ist diese Systemfesteplatte auch wieder "clean".