Hi,
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.
--
greetings
eMHa
pgpB8Br0uQV5a.pgp
Description: PGP signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home