Jeff McCune home
TuxThis 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.
Fork me on GitHub