[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] p2v migration + Xen


Am Dienstag, 18. April 2006 14:53 schrieb Dan Hawker:
> We are using Xen to help keep certain services separate on the LAN but
> also to create multiple virtual machines for safe and easy software
> development across multiple platforms (all Linux based).
> Am looking for some advice/tips/how-tos/whatever to help in a p2v
> migration I am about to undertake.

to avoid kernel and modules failures, i compiled all important things in the 
domU kernel, so i don't have to rely on working module loading (if it's an 
older system which can't cope with newer kernels).

> We have a machine in place that I would like to migrate, however am unsure
> as to what the best option would be. I am not going to get much time for
> the machine in question to be *not available*, so wondered if I could use
> rsync or similar to create a backup of the filesystem in question directly
> into a directory structure on the new server for the resultant Xen VM. I
> could do this whilst all things are still live. At the moment we'd like to
> swap over, we could then do a quick and final rsync, turn off the original
> server and bring the Xen VM up.

So this is as i've done it with minimal downtime of the services, also 
including ip migration with dnat and snat on the old host to the new host. My 
preference for rsync going from dom0 to the new virtual disk wich is mounted 
in /mnt was:
# rsync --archive --numeric-ids --hard-links \
    --one-file-system --delete \
    --compress --rsh=ssh --verbose \
    oldhost:/ /mnt/
numeric-ids is important if you different user to id mappings on dom0 and the 
old host.
one-file-system helps if you don't wan't all these virtual filesystems to be 
synced like /proc and /sys. But be aware if the old host has udev. Also if 
the old host has multiple partitions you can make a rsync of each partition 
and exclude directories who are on different partitions to avaoid that they 
will be removed.
I've managed to keep the downtime short (a few minutes) with prepared 
configurations for the new hosts and dry runs of the new host as domU with a 
private (not connected to any network) ip.
So my final things were, stop all services but ssh on the old host, rsync, 
copy prepared configs, umount /mnt, start the new host and in my case enable 
dnat and snat on the old host.

> Does this make sense??? I presume there will be some directories and files
> that shouldn't be migrated (/dev, /tmp, etc) which files/dirs are safe to
> leave behind???

I like to say rsync to keep on one filesystem so i don't bother which dirs.

> The reason I'd like to move the server over, rather than install a new VM
> and update it, is because as mentioned its a software dev box and has been
> here a while, (before I arrived). Hence I am unsure as to what packages
> and apps have been installed and how.

Yeah, if you do server consolidation a new install is much more work.

Also in my new setups i try to make ip configuration minimal in the system and 
rely on the per xen config (kernel config) ip configuration. So with my 
storage system behind i can make snapshots of a live system and start this on 
a private ip to test updates and other big configration changes.

I'm also proud to say that i've migrated a lot of live servers to a new 
hosting center with downtimes from 3 to 15 minutes and only one server with 
downtime of services of 45 minutes, but this only because the old server was 
that slow when doing the last rsync (a lot of files and a lot of big zope 
databases). So server consolidation is really possible with xen.



Attachment: pgp0fgBbNdruU.pgp
Description: PGP signature

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.