{"id":4062,"date":"2014-12-10T00:37:23","date_gmt":"2014-12-09T16:37:23","guid":{"rendered":"http:\/\/rmohan.com\/?p=4062"},"modified":"2014-12-10T00:38:45","modified_gmt":"2014-12-09T16:38:45","slug":"rename-volume-group-on-which-your-root-partition-resides","status":"publish","type":"post","link":"https:\/\/mohan.sg\/?p=4062","title":{"rendered":"Rename volume group on which your root(\/) partition resides."},"content":{"rendered":"
We had few of the servers which was similar in file systems, disk partitions, applications, etc .., but was exception in only Volume Group(VG). So I had cloned the systems and thought of renaming the VG, but since root<\/b>\u00a0Logical Volume(LV) was configured on the same VG was unable to un-mount online. I had to bring down the server to perform below steps.<\/div>\n
<\/div>\n
Below has been performed on CentOS-6.3 32-bit kernel version –\u00a02.6.32-279.el6<\/b><\/div>\n
\u00a0<\/b><\/div>\n
Since it is root volume, we need to umount the file system, insert the CentOS CD\/DVD to boot <\/b>server in rescue shell.<\/b><\/div>\n
#boot: linux rescue<\/div>\n
<\/div>\n
when it prompts for the questions, choose your answers.<\/div>\n
Question 5 : Rescue window<\/div>\n
Offers to mount Linux installation in rw, read only or not at all. Either way, we will be provided with a shell. As this system’s root partition is on a logical volume in the volume group we wish to rename, we must not mount the system. [ SKIP ]<\/div>\n
<\/div>\n
Make sure all your logical volumes are OFFLINE<\/div>\n
<\/div>\n
\n
# lvm lvscan<\/div>\n
\u00a0 INACTIVE \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0‘\/dev\/vg_pcmk1\/home’ [1.00 GiB] inherit<\/div>\n
\u00a0 INACTIVE \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0‘\/dev\/vg_pcmk1\/rootvg’ [13.18 GiB] inherit<\/div>\n
\u00a0 INACTIVE \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0‘\/dev\/vg_pcmk1\/swap’ [1.46 GiB] inherit<\/div>\n
#<\/div>\n
<\/div>\n
#lvm vgscan<\/div>\n
found volume group vg_pcmk1<\/div>\n
.<\/div>\n
.<\/div>\n
(output omitted)<\/div>\n
<\/div>\n
– Rename the volume group<\/div>\n
#lvm rename\u00a0vg_pcmk1\u00a0vg_pcmk2<\/div>\n
<\/div>\n
– Exit the shell and reboot the server. Let CentOS DVD be in the disk.<\/div>\n
#exit<\/div>\n
<\/div>\n
– Reboot the server in the rescue environment and while in Question 5, choose Continue<\/b><\/div>\n
\u00a0<\/b><\/div>\n
\n
Eventually, a shell will appear. The system files are in \/mnt\/sysimage. \u00a0chroot into the system:<\/div>\n
# chroot \/mnt\/sysimage<\/div>\n
<\/div>\n
sh-4.1#vim \/etc\/fstab<\/div>\n
– Change the entries of the volume group for the logical volumes which are residing.<\/div>\n
<\/div>\n
\n
# grep vg_pcmk2 \/etc\/fstab<\/div>\n
\/dev\/mapper\/vg_pcmk2-rootvg \/ \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ext4 \u00a0 \u00a0defaults \u00a0 \u00a0 \u00a0 \u00a01 1<\/div>\n
\/dev\/mapper\/vg_pcmk2-home \/home \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ext4 \u00a0 \u00a0defaults \u00a0 \u00a0 \u00a01 2<\/div>\n
\/dev\/mapper\/vg_pcmk2-swap swap \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0swap \u00a0 \u00a0defaults \u00a0 \u00a0 \u00a0 \u00a00 0<\/div>\n
#<\/div>\n<\/div>\n
<\/div>\n
– Change an entry in grub.conf file.<\/div>\n
#vim \/boot\/grub\/grub.conf<\/div>\n
\n
# grep vg_pcmk2 \/boot\/grub\/grub.conf<\/div>\n
\u00a0 \u00a0 \u00a0 \u00a0 kernel \/vmlinuz-2.6.32-279.el6.i686 ro root=\/dev\/mapper\/vg_pcmk2-rootvg rd_LVM_LV=vg_pcmk2\/rootvg rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto \u00a0KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rd_LVM_LV=vg_pcmk2\/swap rhgb quiet<\/div>\n
#<\/div>\n<\/div>\n
<\/div>\n
– Create a newly initrd image as below.<\/div>\n
\n
# tail -1 \/boot\/grub\/grub.conf<\/div>\n
\u00a0 \u00a0 \u00a0 \u00a0 initrd \/initrd-2.6.32-279.el6.i686.img<\/div>\n
#<\/div>\n<\/div>\n
<\/div>\n
As updated above, create new initrd image and this will take some time and will have no output.<\/div>\n
#mkinitrd \/boot\/initrd-$(uname -r).img $(uname -r)<\/div>\n
<\/div>\n
\n
– Exit from shell:<\/div>\n
# exit<\/div>\n
<\/div>\n
– Exit from Linux rescue:<\/div>\n
# exit<\/div>\n<\/div>\n
<\/div>\n
– Remove the CD and boot the server.<\/div>\n
<\/div>\n
Once your server logins, check the VG name, it would be successfully changed.<\/div>\n
# df -h | grep vg_pcmk2<\/div>\n
\n
\/dev\/mapper\/vg_pcmk2-rootvg<\/div>\n
\/dev\/mapper\/vg_pcmk2-home<\/div>\n
#<\/div>\n<\/div>\n
<\/div>\n
NOTE: If no proper entries in root volume being made, kernel gets PANIC and will not sync and kills init process.<\/b><\/div>\n
<\/div>\n
<\/div>\n
\n

Since this is a new blog, I\u2019ve 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\u2026. \u00a0We\u2019ve all been that poor slob at one time ;-><\/p>\n

Even if you\u2019re 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\u2019s discussed.<\/p>\n

Why Rename a VG?<\/h2>\n

Generally, you should NEVER rename LVM Volume Groups unless you like pain. Running \u2018vgrename\u2019<\/b>\u00a0will change the name of the Volume Group- EXCEPT where it matters most: \u2018initrd\u2019<\/b>\u00a0. 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.<\/p>\n

A client asked me to rebuild a KVM Hypervisor several years ago. \u00a0Part of the brief was to migrate the VM\u2019s on it which were running as .img<\/em> files in \/var\/lib\/libvirt<\/em> to LVM partitions on the KVM Hypervisor itself. \u00a0Unfortunately for me, the previous sysadmin had used the default \u201cVolGroupXX<\/em>\u201d naming convention inside all the VMs. \u00a0When 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. \u00a0However, when the VMs\u2019 filesystems were squirted into LVM partitions on the KVM host, that\u2019s where the conflict between shared VG names arose.<\/p>\n

As a consequence, assuming the KVM Hypervisor Volume Group is itself not named\u00a0VolGroupXX<\/em>too, every VM you migrate will have a conflict with other VM\u2019s VolGroupXX<\/em> naming scheme unless you change them . \u00a0Good grief Charlie Brown. \u00a0 This can all be avoided by naming the Volume Group after the hostname it lives on to ensure its\u2019 uniqueness. But that wasn\u2019t an option and I had to rename the Volume Groups.<\/p>\n

Rename the Volume Group of a VM<\/h2>\n

This example entails migrating a named \u201cmyVM.img<\/em>\u201d running from a file to an LVM partition on the Hypervisor hosting it.<\/p>\n

1. Create LVM partition on the Hypervisor where we can dd the VM into:<\/p>\n

lvcreate  -L 10G -n myVM  KVMhypervisorVolGroup00<\/pre>\n
2. Unmount the running VM, \u201cmyVM.img<\/em>\u201d running from \/var\/lib\/libvirt\/images\/:<\/p>\n
unmount \/var\/lib\/libvirt\/images\/<\/pre>\n
3. Squirt the VM\u2019s image file into the LVM partition \u201cmyVM<\/em>\u201d just created on the Hypervisor. In this example, the VM file we\u2019re moving to the partition resides in the default folder for KVM images. As a general practice when using dd,\u00a0ALWAYS<\/b>\u00a0double check you haven\u2019t flip-flopped the input and output parameter values before hitting the return key.<\/p>\n
dd if=\/var\/lib\/libvirt\/images\/myVM.img of=\/dev\/KVMhypervisorVolGroup00\/myVM<\/pre>\n
4. Create device maps for the new partition where the VM has been moved so Device Mapper can find it:<\/p>\n
kpartx -av \/dev\/KVMhypervisorVolGroup00\/myVM<\/pre>\n
5. Scan and rebuild Volume Group caches:<\/p>\n
vgscan<\/pre>\n
6. Determine the UUID of the of \/dev\/KVMhypervisorVolGroup00\/myVM<\/b><\/em>\u00a0(the LV which the VM was migrated into):<\/p>\n
vgdisplay<\/pre>\n
If you\u2019re trying to identify two hosts sharing the same Volume Group name, you need to do this by UUID. \u00a0It is CRUCIAL that you identify correctly the UUID of VolGroup00<\/em> belonging to the VM you want to modify. Check the space of the \u201cVG Size\u201d details in the output of the vgdisplay command to differentiate between which UUID belongs to which VM.<\/p>\n
7. Rename the Volume Group\u00a0FROM \u201c\/dev\/VolGroup00<\/b><\/em>\u201d TO \u201c\/dev\/VolGroupMyVM<\/b>.\u201d By using the convention of replacing \u201c00<\/b>\u201d in the Volume Group name with the VM\u2019s hostname, we can ensure that the VG name is unique and we won\u2019t bump into the problem of duplicate Volume Group names if we move this VM somewhere else in the future.<\/p>\n
Triple check that you are specifying the UUID of the VM\u2019s VolGroup00<\/em> you believe that you are altering before pulling the trigger! The reason we\u2019re feeding the \u2018UUID\u2019<\/b>\u00a0in lieu of the Volume Group name \u2018VolGroup00<\/em>\u2018<\/b>\u00a0to the\u00a0vgrename\u00a0<\/i>command is that the UUID is the only way to accurately distinguish between the two \u201cVolGroup00<\/em>\u201d \u2018s where several are shown.<\/p>\n
vgrename UUID-goes-here<\/b><\/em> \/dev\/VolGroupMyVM\r\n<\/strong><\/em><\/pre>\n
8. \u00a0vgrename<\/em> is only capable of renaming the Volume Group- it doesn\u2019t 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. \u00a0Let\u2019s change this so the VM is absolutely unique from the VM we are migrating away from:<\/p>\n
vgimportclone -n myVM<\/em> \/dev\/mapper<\/b>\/myVM\r\n<\/em><\/pre>\n
9.\u00a0\u00a0Update any references to the VM\u2019s UUID: Since we\u2019ve changed the UUID, anywhere this appears, ie the VM\u2019s fstab, this must also be updated.<\/p>\n
10. Mount the VM to enable working on it\u2019s filesystem:<\/p>\n
mkdir \/mnt\/myVM<\/em>\r\nmount \/dev\/mapper\/myVM<\/em> \/mnt\/myVM\r\n<\/em><\/pre>\n
11. Edit the VM\u2019s grub configuration to reflect the change in the Volume Group name:<\/p>\n
vi \/mnt\/myVM<\/em>\/boot\/grub\/grub.conf<\/pre>\n
FROM:<\/b><\/p>\n
kernel \/vmlinuz-2.6.32-220.7.1.el6.x86_64 ro root=\/dev\/mapper\/VolGroup00<\/b><\/em>-LogVol00 rd_LVM_LV=VolGroup00<\/b><\/em>\/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<\/pre>\n
TO:<\/b><\/p>\n
kernel \/vmlinuz-2.6.32-220.7.1.el6.x86_64 ro root=\/dev\/mapper\/VolGroupMyVM<\/b><\/em>-LogVol00 rd_LVM_LV=VolGroupMyVM<\/b>\/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<\/pre>\n
Modify initrd<\/h2>\n
12. Edit Volume Group specified in the VM\u2019s\u00a0initrd<\/b>\u00a0(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:<\/p>\n
mkdir \/mnt\/myVM\/initrd_edited<\/pre>\n
Copy the initrd image to our work directory:<\/p>\n
cp -p \/mnt\/myVM\/boot\/initrd_image_to_edit.img \/mnt\/myVM\/initrd_edited\/<\/pre>\n
Change the name of the original initrd image to\u00a0.OLD<\/b>:<\/p>\n
mv \/mnt\/myVM\/boot\/initrd_image_to_edit.img  \/mnt\/myVM\/boot\/initrd_image_to_edit.img.OLD<\/b><\/pre>\n
Change directories to where we copied the initrd image to work on it:<\/p>\n
cd \/mnt\/myVM\/initrd_edited\/<\/pre>\n
Decompress the initrd image so it can be edited:<\/p>\n
cat initrd-*|gzip -d|cpio -i<\/pre>\n
Delete the compressed copy in THIS directory:<\/p>\n
rm initrd-*<\/pre>\n
Change the Volume Group in init FROM:\u00a0VolGroup00<\/b><\/em>\u00a0TO:\u00a0VolGroupMyVM<\/b><\/em><\/p>\n
vi init<\/pre>\n
Finally, compress the modified initrd back into an image and squirt the compressed image back to the VM\u2019s\u00a0\/boot<\/i>\u00a0directory.<\/p>\n
*!!!DANGER WILL ROBINSON, DANGER!!*:<\/b>\u00a0Ensure that you pipe this to the correct directory to avoid overwriting the Hypervisor\u2019s initrd!!!<\/p>\n
find|cpio -H newc -o|gzip>..\/originalInitrdName.img<\/pre>\n
13. Edit the VM\u2019s fstab to change references of\u00a0VolGroup00<\/b><\/em>\u00a0TO\u00a0VolGroupMyVM<\/b><\/em>\u00a0so everything will mount correctly:<\/p>\n
vi \/mnt\/myVM\/etc\/fstab<\/pre>\n
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\u2019ll be dropped into a maintenance prompt:<\/p>\n
Enter root password at maintenance prompt\r\nmount -o remount -rw \/\r\nvi \/etc\/fstab\r\nMake your changes to fstab, save them and finally:\r\nshutdown -r now<\/pre>\n
15. Unmount the LVM volume that you mounted to work on the VM:<\/p>\n
umount \/mnt\/myVM<\/pre>\n
Done. Repeat for each VM you\u2019re dropping into a partition on the Hypervisor with the Volume Group \u201cVolGroup00<\/strong><\/em>\u201d \u2026<\/p>\n
Think that about does it. \u00a0 Hope somebody found this useful to alleviate the pain I had correcting the mess. \u00a0If you find working through the steps that I\u2019ve made any\u00a0omissions\/transpositions errors, lemme know and I\u2019ll update the blog post.<\/p>\n
 <\/p>\n
 <\/p>\n
\n
Rename a Volume Group in Red Hat Enterprise Linux 6 (RHEL6)<\/a><\/h1>\n<\/div>\n
\n
WARNING:\u00a0 Perform this at your own risk and double check LVM documentation!<\/div>\n
* As always this will work perfectly well in CentOS 6.<\/div>\n
<\/div>\n
As I was preparing a new VMware guest host to be my template master I realized AFTER the\u00a0 RHEL6 install that I failed to rename the default volume group from vg_hostname<\/b>-lv_root to something more generic for a VM template server.<\/p>\n
This was surprisingly simple and straight forward, even booted up onto the guest host’s boot drive – no need to boot into rescue or emergency mode – just don’t muk it up.\u00a0 Simply do the following (and be careful):<\/p>\n
\n
As root user (or using sudo) be sure to make backup copies of these two files in case you muk it up, and ensure you know how to boot up in rescue mode with other boot media.<\/div>\n
# cp \/etc\/fstab \/etc\/fstab.orig<\/div>\n
# cp \/boot\/grub\/grub.conf \/boot\/grub\/grub.conf.orig<\/div>\n
<\/div>\n
Rename your volume group (vg)<\/p>\n
<\/div>\n
# vgrename \/dev\/vg_OLDname \/dev\/vg_NEWname<\/div>\n<\/div>\n
Now change all instances of the old volume group in the following files:<\/p>\n
\/etc\/grub.conf\u00a0 (which is a symbolic link to \/boot\/grub\/grub.conf)<\/p>\n
\/etc\/fstab<\/div>\n
mv \/boot\/initramfs-$(uname -r).img \/boot\/initramfs-$(uname -r).img.backup<\/p>\n
dracut -v \/boot\/initramfs-$(uname -r).img $(uname -r)<\/p>\n<\/div>\n
\u00a0dracut<\/div>\n
<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
We had few of the servers which was similar in file systems, disk partitions, applications, etc .., but was exception in only Volume Group(VG). So I had cloned the systems and thought of renaming the VG, but since root Logical Volume(LV) was configured on the same VG was unable to un-mount online. I had to […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,4],"tags":[],"_links":{"self":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/4062"}],"collection":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4062"}],"version-history":[{"count":2,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/4062\/revisions"}],"predecessor-version":[{"id":4065,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/4062\/revisions\/4065"}],"wp:attachment":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4062"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4062"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4062"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}