Thursday, July 3, 2008

Moving disks with LVM on them

Not really related to the theme of this blog, but I had quite a ride with LVM (Logical Volume Manager) recently. I upgraded to a new machine lately (Dell SC 1430) so that I can use all the cool virtualization on my desktop. My old machine was still hanging around because I have some old apps on it which need pinned Debian packages. Last week, the machine died: seems a motherbaord issue, because even swapping the power supply did not help. So I decided to virtualize the old machine on my new machine. For that, I first had to get the old disk working again. It's a 500GB IDE disk. Luckily, the newmachine still supports IDE. Only problem is that the cables (both data and power) are so short that I can't connect both the DVD and disk at the same time. I don;t use the DVD that often, so that should not be a problem. I unplugged the DVD, plugged in the disk, and rebooted. This was when the problems started: I did use the same volume group name (vg0) on both the old and the new machine, and there were also name clashes in logical volumes (eg vg0/home). Nicely enough LVM picked the LVs from the new disk instead of the old ones, so I had a working system. But I could not mount the old filesystems because of the name clashes.

The solution seemed quite simple: rename the old volume group from vg0 to vg1 and all should be fine. After some reading I found vgrename and also that it supports addressing volume groups using UUIDs. Trouble is that vgrename only works if all its logical volumes are offline. And lvchange does _not_ accept UUIDs as volume group names. After baning my head and some googleing, I decided I need to boot off a live CD. Remember that I had to disconnect my DVD... So I first had to unplug the disk again, plug in the DVD, and boot of the CD. Renaming the volume group on the old disk was ofd course not an option anymore. so I had to rename the volume group of the new disk. However, I could not even access the partition beause the LVM is installed on top of a SW-RAID1, and I did not have the correct mdadm.conf file. Some more googleing finally led me to "mdadm -A -a y --scan --auto -c 1 /dev/sda2 /dev/sdb2" which creates /dev/md1 out of the 2 partitions. After that, it was just a "vgrename vg0 vg1". Nest step was to powerofff again, unplug the DVD, replug the disk and boot. This resulted in booting from the old disk because grub had vg-root as root partition and the new disk now was vg1-root. So reboot again and adjust root partition in grub from /dev/mapper/vg0-root to /dev/mapper-vg1-root. This booted from the correct disk, but with the filesystems from the old disk becuase /etc/fstab also had vg0 in it. Luckily, /etc was on the root partition and perl as well, so I changed fstab using "perl -p -i -e 's/vg0/vg1/g' /etc/fstab /boot/grub/menu.lst" and booted again. Now I was in business: system booted off the new disk and mounted all file systems correctly, and no more name clashes.

I then mounted the old root filesystem onto /tmp/old and the other old filesystems onto that. "chroot /tmp/old" now gives me access to my old system. Overall, this took me like 2 hours (including googling), so bad, but not too bad. Would be really good if lvchange would accept VG UUIDs though, because then all woudl have been over within 10 minutes.

I can't simply virtualizse the complete old system because I don't want to waste so much space, so I will now set up a new virtual machine and copy the old app and it's dependencies over. Hopefully will be done over the weekend.