Booting Xen paravirtualized vm in rescue mode

This is my first post in english. I am sorry if there are some mistakes – it is not my native language :-)

Recently I had to rename volume group in one of my virtual machines. It is based on CentOS (both dom0 and domU) and it was paravirtualized. I couldn`t do it on running system because root partition was on logical volume. I had to boot the machine in rescue mode. I had no idea how to boot from CD/DVD iso image – AFAIK it is impossible on pv guests. I had to boot vm directly from kernel and initrd used in installation (both are xen aware). So I copied  them to /tmp/xen from /images/xen/ on CD/DVD installation disc.

Then I had to comment out the following line from vm`s config file to bypass pygrub bootloader:

#bootloader = "/usr/bin/pygrub"

Now I needed to tell my vm to use kernel and initrd I had previously copied so I added the following lines:

kernel = "/tmp/xen/vmlinuz"
ramdisk = "/tmp/xen/initrd.img"
extra = "rescue method=http://192.168.0.2/install/centos/"

The last line passes extra arguments to kernel. There is a rescue keyword and a method which tells anaconda installer to get install files from my http server.

After that I was able to boot vm in rescue and rename my LVM virtual group.

Klastrowy LVM i Xen

Bardzo intensywnie wykorzystuję wirtualizację jaką oferuje CentOS, czyli opensource`ową wersję Xena. W połączeniu z LVM można bardzo efektywnie zarządzać maszynami m.in. poprzez snapshoty. Dodatkowo zastosowanie LVM jako backendu storage`owego owocuje wysoką wydajnością.

Xen posiada również możliwość migracji maszyn. Funkcja ta znana jako live migration jest odpowiednikiem vmotion dla produktów VMware. Można ją wykorzystać jedynie w przypadku, gdy wszystkie serwery dom0 mają dostęp do współdzielonego storage`u. Najłatwiej jest wykorzystać zasób NFS podmontowany na wszystkich serwerach, a maszyny wirtualne instalować na plikach (obrazy dysków) tam umieszczonych. Oczywiście tracimy na wydajności, a poza tym NFS nie wydaje się dobrym pomysłem dla większych instalacji.
I tu z pomocą przychodzi klastrowa odmiana LVM (CLVM). W RHEL/CentOS demon zarządzający klastrową częścią LVM (clvmd) komunikuje się z menadżerem klastra RHCS (Red Hat Cluster Suite). Mi osobiście to niezbyt pasuje. Nie tylko chyba ja uważam, że twór RHCS nie jest jeszcze stabilny ani też łatwy w konfiguracji i zarządzaniu/utrzymaniu. Ale to już chyba temat na odrębny wpis. Ku czemu innemu zmierzam. Mianowicie bardzo zainteresował mnie ten wpis. Okazuje się, że jest możliwe zmuszenie CLVM do działania bez skonfigurowanego RHCS! Należy zamiast tego użyć openais, który i tak wchodzi w skład RHCS. Jako odrębna część jest jednak o wiele przyjemniejsza w zarządzaniu i konfiguracji. Zachęcony wspomnianym wpisem przystąpiłem do pracy. Udało mi się przerobić paczkę lvm2-cluster, tak aby linkowała się z openais. Wpis ten byłby chyba pierwszym howto w sieci opisującym ten proces dla systemów RHEL/CentOS. Niestety w trakcie działania pojawiają się wycieki w pamięci w demonie aisexec. Przy każdorazowym wysłaniu wiadomości do aisexec przez demon clvmd ten pierwszy rezerwuje około 6MB pamięci i nie zwalnia jej poprawnie. Kilkunastogodzinne próby nie przyniosły rozwiązania. Wielka szkoda. Byłaby to świetna wiadomość i dalsze pole do eksperymentowania. Liczę, że uda mi się jeszcze powrócić do tematu, a o rezultatach postaram się niezwłocznie poinformować.