This is just a record of a problem I ran into today. I've been working with two CentOS 5 Opteron servers connected to a shared SAN, and I'm using LVM tags to arbitrate activation of the correct volumes on the correct hosts.
While hacking at /etc/lvm/lvm.conf, I apparently forgot this file is copied into initial ram disk images in order to make a root device sitting on a LVM logical volume available to the kernel at boot.
I configured LVM to only activate devices with tags matching the host tags, which posed a problem when I upgraded to kernel 2.6.18-8.1.8.el5. At boot, the initial ram disk failed to activate any logical volumes because the tags were incorrect.
The solution was to make sure I specifically list the system volume group in lvm.conf, in addition to the host tags. For example, the following is correct:
tags { hosttags = 1 }
activation { volume_list = [ "@*", "VolGroup00" ] }
While the following configuration doesn't activate any volumes:
tags { hosttags = 1 }
activation { volume_list = [ "@*" ] }
LVM Tags are a really nice feature. It allows me to control what logical volumes sitting on the shared SAN are activated by which of the hosts in the cluster. For example:
[root@xen02 ~]# lvdisplay @`uname -n` | grep /dev/
LV Name /dev/xensan/test01.rootfs
LV Name /dev/xensan/test01.swapfs
LV Name /dev/xensan/test-webserver
[root@xen03 ~]# lvdisplay @`uname -n` | grep /dev/
LV Name /dev/xensan/dns1.swapfs
LV Name /dev/xensan/dns1.rootfs
LV Name /dev/xensan/newtest
LV Name /dev/xensan/ns1.vm
LV Name /dev/xensan/test2.vm
Shared block devices are nice; they facilitate live migration of guest domains between the two xen hosts.
