Migrating An OS Installation from a Physical Machine to a Xen Paravirtual Guest

It has been said that it's possible to do the above. Does
anybody have
details of how one might go about it?  It's easy enough to
create, then
extract from .. tar images. 

But I can't figure how to do the grub stuff.  Suggestions?
-- 
 Graham Jenkins +61 3 9925 4909 
 Victorian Partnership for Advanced Computing http://www.vpac.org/
 PO Box 201, Carlton South, Vic. 3053, Australia
 

--
Fedora-xen mailing list
Fedora-xenredhat.com
ht
tps://www.redhat.com/mailman/listinfo/fedora-xen

On Tue, Apr 03, 2007, Graham Jenkins wrote:
> It has been said that it's possible to do the above.
Does anybody have
> details of how one might go about it?  It's easy enough
to create, then
> extract from .. tar images. 
> 
> But I can't figure how to do the grub stuff. 
Suggestions?

Do you need to use py-grub?

All my migrations worked fine - move the entire OS into an
LVM, install the
Xenified kernel inside the VM and in dom0 so the kernel can
boot from dom0
and the modules can load inside domU; install Xen-happy
libraries so you
don't get hit by the massive amounts of logging the
Redhat/fedora kernels do
when dealing with fixing up segment hacks.

I haven't had (yet) to use py-grub.




Adrian

--
Fedora-xen mailing list
Fedora-xenredhat.com
ht
tps://www.redhat.com/mailman/listinfo/fedora-xen

On Tue, 2007-04-03 at 09:28 +0800, Adrian Chadd wrote:
> On Tue, Apr 03, 2007, Graham Jenkins wrote:
> > It has been said that it's possible to do the
above. Does anybody have
> > details of how one might go about it?  It's easy
enough to create, then
> > extract from .. tar images. 
> > 
> > But I can't figure how to do the grub stuff. 
Suggestions?
> 
> Do you need to use py-grub?
> 
> All my migrations worked fine - move the entire OS into
an LVM, install the
> Xenified kernel inside the VM and in dom0 so the kernel
can boot from dom0
> and the modules can load inside domU; install Xen-happy
libraries so you
> don't get hit by the massive amounts of logging the
Redhat/fedora kernels do
> when dealing with fixing up segment hacks.
> 
> I haven't had (yet) to use py-grub.

OK .. but how do you make the FC6 Xen kernel access physical
partions.
Something like:
--
disk = [ 'phy:VolumeGroup00/ng2Root,sda1,w',
         'phy:VolumeGroup00/ng2Swap,sda2,w']
--
.. doesn't work with the supplied Xen kernel.


-- 
 Graham Jenkins +61 3 9925 4909 
 Victorian Partnership for Advanced Computing http://www.vpac.org/
 PO Box 201, Carlton South, Vic. 3053, Australia
 

--
Fedora-xen mailing list
Fedora-xenredhat.com
ht
tps://www.redhat.com/mailman/listinfo/fedora-xen

On Tue, Apr 03, 2007, Graham Jenkins wrote:
> On Tue, 2007-04-03 at 09:28 +0800, Adrian Chadd wrote:
> > On Tue, Apr 03, 2007, Graham Jenkins wrote:
> > > It has been said that it's possible to do the
above. Does anybody have
> > > details of how one might go about it?  It's
easy enough to create, then
> > > extract from .. tar images. 
> > > 
> > > But I can't figure how to do the grub stuff. 
Suggestions?
> > 
> > Do you need to use py-grub?
> > 
> > All my migrations worked fine - move the entire OS
into an LVM, install the
> > Xenified kernel inside the VM and in dom0 so the
kernel can boot from dom0
> > and the modules can load inside domU; install
Xen-happy libraries so you
> > don't get hit by the massive amounts of logging
the Redhat/fedora kernels do
> > when dealing with fixing up segment hacks.
> > 
> > I haven't had (yet) to use py-grub.
> 
> OK .. but how do you make the FC6 Xen kernel access
physical partions.
> Something like:
> --
> disk = [ 'phy:VolumeGroup00/ng2Root,sda1,w',
>          'phy:VolumeGroup00/ng2Swap,sda2,w']

disk = [ 'phy:data/XEN_cindy_root,sda1,w',
'phy:data/XEN_cindy_swap,sda2,w' ]

Linux hosting-2 2.6.18-1.2257.fc5xen0 #1 SMP Fri Dec 15
17:35:10 EST 2006 i686 athlon i386 GNU/Linux

Watch your domU dmesg and make sure that there's no errors
relating
unmatched Xen devices or such; you need to be sure the domU
has the Xen block and network devices loaded (the Xen block
device
being loaded in initrd or compiled into the kernel!) or
your
domU won't be able to mount the root device.



Adrian

--
Fedora-xen mailing list
Fedora-xenredhat.com
ht
tps://www.redhat.com/mailman/listinfo/fedora-xen

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 <lamontgurulabs.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

--
Fedora-xen mailing list
Fedora-xenredhat.com
ht
tps://www.redhat.com/mailman/listinfo/fedora-xen