Since this is a new blog, I’ve been trolling through my Wiki looking for things that if not of broad general interest, are so esoteric and complicated that it might help some poor slob(s) Googling in futility, slowly losing the will to live….  We’ve all been that poor slob at one time ;->

Even if you’re not interested in renaming an LVM Volume Group per se, this blog post also demonstrates how to tweak an initial RAM disk, which I guess might be of broader interest than the special case in which it’s discussed.

Why Rename a VG?

Generally, you should NEVER rename LVM Volume Groups unless you like pain. Running ‘vgrename’ will change the name of the Volume Group- EXCEPT where it matters most: ‘initrd’ . The Initial RAM Disk references the Volume Group when trying to mount the root file system. If the Volume Group is incorrectly specified there, obviously the system will not boot.

A client asked me to rebuild a KVM Hypervisor several years ago.  Part of the brief was to migrate the VM’s on it which were running as .img files in /var/lib/libvirt to LVM partitions on the KVM Hypervisor itself.  Unfortunately for me, the previous sysadmin had used the default “VolGroupXX” naming convention inside all the VMs.  When the LVM structures were internal to the VM itself in their .img files they co-existed happily together despite all having the same Volume Group names.  However, when the VMs’ filesystems were squirted into LVM partitions on the KVM host, that’s where the conflict between shared VG names arose.

As a consequence, assuming the KVM Hypervisor Volume Group is itself not named VolGroupXXtoo, every VM you migrate will have a conflict with other VM’s VolGroupXX naming scheme unless you change them .  Good grief Charlie Brown.   This can all be avoided by naming the Volume Group after the hostname it lives on to ensure its’ uniqueness. But that wasn’t an option and I had to rename the Volume Groups.

Rename the Volume Group of a VM

This example entails migrating a named “myVM.img” running from a file to an LVM partition on the Hypervisor hosting it.

1. Create LVM partition on the Hypervisor where we can dd the VM into:

lvcreate  -L 10G -n myVM  KVMhypervisorVolGroup00

2. Unmount the running VM, “myVM.img” running from /var/lib/libvirt/images/:

unmount /var/lib/libvirt/images/

3. Squirt the VM’s image file into the LVM partition “myVM” just created on the Hypervisor. In this example, the VM file we’re moving to the partition resides in the default folder for KVM images. As a general practice when using dd, ALWAYS double check you haven’t flip-flopped the input and output parameter values before hitting the return key.

dd if=/var/lib/libvirt/images/myVM.img of=/dev/KVMhypervisorVolGroup00/myVM

4. Create device maps for the new partition where the VM has been moved so Device Mapper can find it:

kpartx -av /dev/KVMhypervisorVolGroup00/myVM

5. Scan and rebuild Volume Group caches:

vgscan

6. Determine the UUID of the of /dev/KVMhypervisorVolGroup00/myVM (the LV which the VM was migrated into):

vgdisplay

If you’re trying to identify two hosts sharing the same Volume Group name, you need to do this by UUID.  It is CRUCIAL that you identify correctly the UUID of VolGroup00 belonging to the VM you want to modify. Check the space of the “VG Size” details in the output of the vgdisplay command to differentiate between which UUID belongs to which VM.

7. Rename the Volume Group FROM “/dev/VolGroup00” TO “/dev/VolGroupMyVM.” By using the convention of replacing “00” in the Volume Group name with the VM’s hostname, we can ensure that the VG name is unique and we won’t bump into the problem of duplicate Volume Group names if we move this VM somewhere else in the future.

Triple check that you are specifying the UUID of the VM’s VolGroup00 you believe that you are altering before pulling the trigger! The reason we’re feeding the ‘UUID’ in lieu of the Volume Group name ‘VolGroup00‘ to the vgrename command is that the UUID is the only way to accurately distinguish between the two “VolGroup00” ‘s where several are shown.

vgrename UUID-goes-here /dev/VolGroupMyVM

8.  vgrename is only capable of renaming the Volume Group- it doesn’t change the UUID of our VM, which we need to do to get the Hypervisor to stop puking errors all over us about duff LVM Volume Groups.  Let’s change this so the VM is absolutely unique from the VM we are migrating away from:

vgimportclone -n myVM /dev/mapper/myVM

9.  Update any references to the VM’s UUID: Since we’ve changed the UUID, anywhere this appears, ie the VM’s fstab, this must also be updated.

10. Mount the VM to enable working on it’s filesystem:

mkdir /mnt/myVM
mount /dev/mapper/myVM /mnt/myVM

11. Edit the VM’s grub configuration to reflect the change in the Volume Group name:

vi /mnt/myVM/boot/grub/grub.conf

FROM:

kernel /vmlinuz-2.6.32-220.7.1.el6.x86_64 ro root=/dev/mapper/VolGroup00-LogVol00 rd_LVM_LV=VolGroup00/LogVol00 rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=uk crashkernel=auto selinux=0 nomodeset

TO:

kernel /vmlinuz-2.6.32-220.7.1.el6.x86_64 ro root=/dev/mapper/VolGroupMyVM-LogVol00 rd_LVM_LV=VolGroupMyVM/LogVol00 rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=uk crashkernel=auto selinux=0 nomodeset

Modify initrd

12. Edit Volume Group specified in the VM’s initrd (Initial RAM Disk) so the root partition can be found and booted: Make a directory to where we can edit a copy of our initrd image:

mkdir /mnt/myVM/initrd_edited

Copy the initrd image to our work directory:

cp -p /mnt/myVM/boot/initrd_image_to_edit.img /mnt/myVM/initrd_edited/

Change the name of the original initrd image to .OLD:

mv /mnt/myVM/boot/initrd_image_to_edit.img  /mnt/myVM/boot/initrd_image_to_edit.img.OLD

Change directories to where we copied the initrd image to work on it:

cd /mnt/myVM/initrd_edited/

Decompress the initrd image so it can be edited:

cat initrd-*|gzip -d|cpio -i

Delete the compressed copy in THIS directory:

rm initrd-*

Change the Volume Group in init FROM: VolGroup00 TO: VolGroupMyVM

vi init

Finally, compress the modified initrd back into an image and squirt the compressed image back to the VM’s /boot directory.

*!!!DANGER WILL ROBINSON, DANGER!!*: Ensure that you pipe this to the correct directory to avoid overwriting the Hypervisor’s initrd!!!

find|cpio -H newc -o|gzip>../originalInitrdName.img

13. Edit the VM’s fstab to change references of VolGroup00 TO VolGroupMyVM so everything will mount correctly:

vi /mnt/myVM/etc/fstab

14. If the VM is started without fixing fstab, it can still be done. Since the boot will hang without having first updated fstab with the new Volume Group name prior too booting the host, nothing will mount correctly and you’ll be dropped into a maintenance prompt:

Enter root password at maintenance prompt
mount -o remount -rw /
vi /etc/fstab
Make your changes to fstab, save them and finally:
shutdown -r now

15. Unmount the LVM volume that you mounted to work on the VM:

umount /mnt/myVM

Done. Repeat for each VM you’re dropping into a partition on the Hypervisor with the Volume Group “VolGroup00” …

Think that about does it.   Hope somebody found this useful to alleviate the pain I had correcting the mess.  If you find working through the steps that I’ve made any omissions/transpositions errors, lemme know and I’ll update the blog post.