LVM DomU unter Dom0

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/" ./init
cd ~/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.