CentOS - Jan 2011 - replace x86 with x64 system and reuse existing LVM

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

On Sun, Jan 9, 2011 at 5:31 PM, Kai Schaetzl <maillists at conactive.com>
wrote:
> 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?
Backup your existing configuration, especially /etc and /home, and
/var/ configurations, and re-install from scratch.

Swapping kernel and glibc dependencies live is very tricky, almost as
tricky as switching from i386 to sparc or ppc, and likely to break in
the niidst of the process, even with the backwards compatibility of
i386 components under x86_64 libraries. You'd otherwise have to boot
with an x85_64 kernel and glibc and operatte inside a chroot cage,
andn that's just bloody tricky to be sure you got it right to replace
components like glibc inside of.

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

At Sun, 09 Jan 2011 23:31:25 +0100 CentOS mailing list <centos at
centos.org> wrote:
> 
> 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?
You should re-install the O/S.  You can re-use the existing volumes,
but you should have the installer remake (as in mkfs.ext2/3) the root
(/), /var, and /usr file systems.  You can keep /home, etc. as is
(assuming it is a separate file systems.  If you have enough space
available in your volumn group, you can create a new root file system
for the 64-bit system and use that.  You can re-use the /boot file
system if you plan on making things 'dual boot'.  You can do this
(except create new logical volumns, unless you are using the GUI
installer)) from the 'custom layout' screen in the installer.
> 
> Thanks,
> 
> Kai
> 
> 
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
> 
>
-- 
Robert Heller             -- 978-544-6933 / heller at deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

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

-- 
Get your web at Conactive Internet Services: http://www.conactive.com