Kai Schaetzl writes:

I want to replace an existing 32bit with a 64bit installation (Centos 5). There's an existing LVM with lots of partitions. Most are used for Xen guests. The system itself uses only one of them plus a separate /boot partition that is not on LVM. What's the best course of action here? Should I do the reinstall with kickstart or better manually and reuse the existing filesystem? As I understand once LVM gets loaded it should find the volumes by itself, but will it be able to use the same naming scheme for instance? Or do I have to do some additional stuff, anyway?

Thanks,

Kai

Kai,

Make sure you backup your config files and whatever else is important for you (especially /etc/xen and/or /etc/libvirt if the machine is mainly dom0) and reinstall from scratch. Install from CD/DVD and be _very_ careful with the partitions. If you get it right, all volumes should be preserved. I did this a couple of times without problems (and will do it again once Centos 6 is released :> ).

-- Nux! www.nux.ro

On Sunday, January 09, 2011 05:31:25 pm Kai Schaetzl wrote:

As I understand once LVM gets loaded it should find the volumes by itself, but will it be able to use the same naming scheme for instance? Or do I have to do some additional stuff, anyway?

I've done this, and there are a couple of things I did to help make sure I didn't accidentally lose data.

First, boot into a rescue environment, or unmount the logical volume(s) on the volume group you want to reuse. Deactivate the logical volume(s) on the volume group you want to reuse with vgchange -an VOLGROUP; then use vgexport VOLGROUP. This will prevent the install from accidentally doing much of anything with that volumegroup.

Do the install, use the custom partitioning, and only set up and reformat the filesystems you don't want to keep. In my own practice, I don't even set up the mount points for the filesystems that I do want to reuse at this point; I wait until the install is finished, I'll reboot the system, make sure everything is working, pull in updates, etc, and then I'll set up the mount points for /home and other filesystems I want to reuse.

If you've done the vgexport, the new install won't activate the logical volumes automatically; use vgimport to register that volume group with the new install, and then use vgchange -ay to reactive the logical volumes. You can then mount them where you want to, etc, and re-setup you Xen, etc.

This is just safe practice. In my case, I was doing a C5 32-bit to C5 64-bit migration, with right at 16TB of backup data at the DR co-lo, and I really really really didn't want to have to spend the very long time necessary to re-mirror all that data over. Better safe than sorry.

The vgexport/vgimport process is just a means of administratively marking the volume group as one being moved, and puts a brick wall of sorts that helps prevent accidental corruption/overwrites. It can be used in a SAN environment to move volumes between hosts, too, and with the right SAN and the right HBA's can be done live with the hosts running. Have done that one on EMC Clariion hardware; AccessLogix to do the host reassignment, and rescan_scsi_bus.sh to make the hosts pick up the new LUNs dynamically, while running.

I've done this now and the procedure is fairly easy and very safe. I did a test run with VMs first, of course.

You don't need to vgchange/vgexport etc. These changes do not carry over, anyway. A new system will find all volumes and make them active. But this doesn't matter.

For a kickstart installation you simply change the previously used disk config lines a bit, like this:

partition /boot --fstype ext3 --onpart=sda1 partition pv.2 --onpart=sda2 volgroup dom0 --noformat pv.2 logvol swap --name=swap --vgname=dom0 --noformat logvol / --fstype ext3 --name=root --vgname=dom0 --useexisting

This reuses sda1 for /boot, sda2 for the volume group, an lv swap for swap without a reformat and an lv root for /, reformatting it. For an installation on real partitions only you use only the --onpart command.

Hope this helps someone in the future.

Kai