[Fedora-xen] Migrating An OS Installation from a Physical Machine to a Xen Paravirtual Guest

[Lamont Peterson]

On Wed, 2007-04-04 at 20:27 +0530, Deependra Shekhawat wrote:
> Sorry. I guess I pointed to wrong area. I understood what you plan to
> do. 
> Can you please tell me how should I proceed in step by step manner. I
> also plan to migrate my RHEL5 installation on physical machine to a
> xen virtual machine. 
> Thanks in advance.

I've been working on the same thing.  I'm very close to having it all
figured out.  Here's a nutshell version:

1.  Create a Xen guest config file for the "new" guest (the one you are
converting from a bare-metal system).  This is easiest if you install
the xen and kernel-xen packages on the machine you are converting and
reboot into the Xen kernel.

2.  There are a few options for allocating storage space for guests;
pick the one you want.  In either case, don't forget about a swap
partition; make sure there is enough space for that too.  I just create
a root and a swap partition on mine.

2a.  If you want to have an image file for the new guest's disk, use dd
to create a disk image file large enough for all the partitions you
want.

2b.  If you are going to use shared storage (fibre channel, iSCSI, AoE,
clvm/GFS, etc.) then create the appropriate storage location.  This is
the method that I prefer.

3.  Create partitions on the new storage.

3a.  If you went with 2a, then use losetup to make the image file a
device (like /dev/loop0) and use fdisk on that.

3b.  If you went with 2b, device nodes are simpler to work with.

4.  Format the new storage partitions and prep the swap partitions.  For
either 2a or 2b, you will need to use kpartx to make the necessary
device nodes properly for the partitions within your image file.

4a.  If you went with 2a, then run something like "kpartx
-a /dev/loop0".  You can then format /dev/mapper/loop0p# and use mkswap
on whichever partition you were setting up as the swap device for the
guest.

4b.  If you went with 2b, then run something like "kpartx
-a /dev/vg0/new-guest".  You can them format /dev/mapper/new-guestp# and
use mkswap on which partition you were setting up as the swap device for
the guest.

5.  Mount the new guest's data partitions (such as at /mnt/new-guest or
whatever).

6.  Copy the entire contents of the filesystems for the system you are
converting.  You have to pay careful attention to the virtual
filesystems (/proc/, /sys/, etc.) and the /dev/ directory.  It's best to
create a for loop that will run "cp -a" for all directories in / except
for those, then deal with creating some of the basics that you need to
have within the /dev/ directory manually with mknod (or by reinstalling
the right package(s), such as filesystem, IIRC).

7.  Edit configuration files within the guest image, such
as /etc/inittab, /etc/fstab, the hostname, networking configuration and
so on.

8.  Edit the initrd found within the guest image.  Fedora & Red Hat's
mkinitrd hard codes some things into the /init nash script found within
their initrd images, you're going to have to add in the xenblk.so driver
(in the /lib/ directory in the initrd) and make sure that /init loads
it.  The easiest way of doing this is by copying over an initrd image
from a guest that was created using virt-install or virt-manager, though
I've successfully had edited the initrd for new guests several times
(and in just a couple of minutes).

9.  You could run "rpm -e kernel" within the guest if you want to clear
up the clutter.  Don't worry, you'll still have the kernel-xen package
installed, which is the only one that you need or can even use in the
guests anyway.  If you are going to do this, best do it chroot'ed or
wait until you have the guest up and running.

10.  Unmount all the guest partitions.

11.  Use kpartx (with it's -d switch) to properly take down the
partitions it created earlier.

12.  If you went with 2a, use "losetup -d /dev/loop0" to cleanly "close
up" the image file.

13.  Test it.

One catch on RHEL5 (without updates installed), I found that SELinux was
interfering with xend's attempts to create the block device within the
guest domains.  I'm going to try to track that down soon, but I haven't
had time to test it with the latest updated policy (is there an errata
SELinux targeted policy yet for RHEL5?).  Hopefully, I'll have that
solved before the end of this week.

As you can see, there are a few steps to go through, but it shouldn't be
very hard to do.  As always, make sure your backups are good before
fiddling with the system, just in case something goes wrong.

HTH.

[snip]
-- 
Lamont Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]

NOTE:  All messages from this email address should be digitally signed with my
       0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as
       well as other keyservers that sync with MIT's.Guru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-xen/attachments/20070405/97ed0f81/attachment.sig>