Am Wochenende hatten wir den Fall das bei einer Xen-Instanz das Dateisystem geprüft und ggf. repariert werden musste. Die Xen-Instanz liegt in diesem Fall in einem Image (gast.img) welches mit Hilfe des Block-Tap-Mechanismus (blktap) zur Verfügung gestellt wird.
Inhalt des Images gast.img:
Partition 1 -> /boot Physical Volume -> VolumeGroup00 -> LogVol00 (/) [80 GB]
-> LogVol01 (swap)
Jetzt ist es so, das durch die damals vorgenommene Defaultinstallation das Dateisystem des Wirtes (xenwirt) ebenso aufgebaut ist wie das des Gastsystems:
Partition 1 -> /boot
Physical Volume -> VolumeGroup00 -> LogVol00 (/) [320 GB]
-> LogVol01 (swap)
Ok, zurück zum Thema. Wir wollen das Dateisystem des Gastes checken (fsck) und anschließend einbinden (mounten). Nachfolgend alle notwendigen Schritte:
Mit Hilfe von kpartx alle Partitionen des Images erkennen und die dazugehörige device-map (/dev/mapper/loop<Loopbackdevice>p<Partitions>) erstellen
kpartx -a /xen/gast.img
Angenommen kpartx verwendet jetzt das Loopbackdevice /dev/loop7, dann findet man jetzt die Partitionen des Images unter /dev/mapper/loop7p*. Die erste Partition (/boot) kann man jetzt schon direkt ansprechen und z.B. einbinden (mount /dev/mapper/loop7p1 /mnt/tmp). Durch das Ausführen von vgscan werden jetzt die neu hinzugekommenen VolumeGroups gefunden und diese könnten jetzt sogar eingebunden und verwendet werden. Hier stoßen wir jetzt leider nur auf unser kleines o.a. Problem: Beide VolumeGroups haben den gleichen Namen, nämlich VolGroup00. Damit wir nun die „richtigen“ LogicalVolumes ansprechen können müssen wir die neu hinzugekommene VolumeGroup umbenennen. Dazu kopieren wir uns die UUID der VG (die mit der Größe von 80GB) die uns das Kommando vgs liefert und nutzen die ID als Identifikationsmerkmal.
vgscan
vgs -v
Als neuen Namen verwenden wir nun etwas Eindeutiges.
vgrename H3sOYJ-ywTE-vNTf-pm0i-De3zXU VolGroupGuest01
Jetzt können wir die umbenannte VolumeGroup aktivieren damit uns (endlich) unter /dev/VolGroupGuest01/ die Logical Volumes bereitstehen. Einer Überprüfung der root-Partition des Gastes steht nun nichts mehr im Weg.
vgchange -ay VolGroupGuest01
fsck.ext3 -C -f /dev/VolGroupGuest01/LogVol00
Da wir den Namen der VolumeGroup nach dem fsck jetzt nicht wieder in VolGroup00 umbenennen können (da es diese VG ja schon gibt!), ist es Notwendig das Gastsystem anzupassen. Wir binden das Gastsystem unter /mnt/guest1 ein und ändern die Grubkonfiguration /boot/grub/grub.conf, die /etc/fstab und die initrd folgendermaßen ab:
Einbinden des Gastsystems:
mount /dev/VolGroupGuest01/LogVol00 /mnt/guest1
mount /dev/mapper/loop7p1 /mnt/guest1/boot
Anpassen /etc/fstab
perl -pi -e „s/VolGroup00/VolGroupGuest01/“ /mnt/guest1/etc/fstab
Anpassen /boot/grub/grub.conf
perl -pi -e „s/VolGroup00/VolGroupGuest01/“ /mnt/guest1/boot/grub/grub.conf
Anpassen /boot/initrd-*
mkdir ~/tmp cd ~/tmp cp /mnt/guest1/boot/initrd-<KERNELVERSION>.img ./initrd.gz gunzip initrd.gz mkdir content cd content cpio -id < ../initrd perl -pi -e "s/VolGroup00/VolGroupGuest01/" ./initcd ~/tmp/content find . | cpio --create --format='newc' > ~/tmp/newinitrd cd ~/tmp gzip newinitrd mv newinitrd.gz /mnt/guest1/boot/initrd-<KERNELVERSION>.img
Jetzt können wir das Dateisystem wieder aushängen, die VolumeGroup deaktivieren, das Devicemapping entfernen und das Loop-Device aushängen.
umount /mnt/guest1/boot
umount /mnt/guest1
vgchange -an VolGroupGuest01
kpartx -d /dev/loop7
Das Image steht jetzt wieder wie gewohnt für xen zur Verfügung. In unserem Fall ist der Gast ohne weitere Probleme gebootet.