Hi All, 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. 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. 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??? 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. TIA Dan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 18 Apr 2006, Dan Hawker wrote:> 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. > > 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. > > 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???If you''re not using udev, you''ll want to migrate /dev over. /tmp is also fine. I usually just exclude /proc and /sys.> 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.Sounds quite reasonable to me. It''s similar to how I do it.. ------------------------------------------------------------------------ | nate carlson | natecars@natecarlson.com | http://www.natecarlson.com | | depriving some poor village of its idiot since 1981 | ------------------------------------------------------------------------ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dan Hawker wrote:>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. > >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??? > >This is how I''ve done it, seems to work pretty well. First mount up your prepped Xen disk (file-backed image or LVM, whatever) in Dom0 under /mnt/tmp. You will have to create the partition/volume/file and mkfs it. Then use... rsync -av -e ssh -n \ #dry run -S \ # handle sparse files -H \ # Preserve hard links -W \ # copy files whole -D \ # also get device files --exclude-from="XenCloneExclude" \ root@srchost:/ /mnt/tmp rsync -av -e ssh -n -S -H -W -D --exclude-from="XenCloneExclude" root@srchost:/ /mnt/tmp Remove the -n for the real deal. The contents of XenCloneExclude are: proc/* tmp/* lost+found/ etc/mtab Adjust to your environment. Make sure to run the srchost is in single-user mode (with network up) or shutdown as many services as you possibly can to reduce the chance of data changing beneath you. After copying the data over you can edit /etc/fstab, /etc/hosts and a few other important files to adjust the image for the new environment. -- Some days it''s just not worth chewing through the restraints... Mark D. Foster, CISSP <mark@foster.cc> http://mark.foster.cc/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dan Hawker schrieb:> 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.Hello ! I only wanted to agree to the other people commenting their migration steps as I''m here in the middle of such a migration ( I''m in the phase of testing the "old" productive server setup in a DOMU with a different IP assigned at the moment.) Because the old server uses a bunch of IP''s for virtual webservers with SSL I can''t test everything but thats enough to say that I can do a last rsync with all relevant services disabled on the production machine in a few minutes downtime and get it all up and running in the DOMU on the twin server. One thing will be different: I''m not using XEN with the goal to consolidate servers but I want high availability (and flexibility). My goal is to use the two servers (same hardware Supermicro DualXeon 3.2 Ghz EM64T with 4 GB of RAM and SATA HW-RAID 1) with only 2 DOMU''s and a small DOM0 for management (256 MB or so). The DOMU''s will be mirrored crossover with DRBD (http://www.drbd.org) between the two servers via direct gigabit crossover link. The servers are LVM based but I needed to change the LVM layout a lot for this setup (i.e. DRBD needs a place for metadata). Since one of the servers was only running a test system so far but the other one is really in heavy usage I was able to prepare the spare one from scratch. When I''m done there will be two servers with only one active DOMU that gets nearly all the ressources like CPU and RAM. I will be able to switch on the other DOMU that represents the active DOMU of the other server in a case of failure or for heavy upgrading of the base system. This should also be combined with heartbeat to fail over automatically. I would call this a "shared nothing active-active Webcluster" - with minimal hardware-resources. In case of failure I will have only half the maximum system performance - that is acceptable. What I''m searching now: If someone is doing something similar I would be interested in the heartbeat configuration he/she uses. Perhaps something to think of: My servers were running DEBIAN Sarge (64bit) with the latest official sarge-kernel which is 2.6.8 :-(. I tried to "xenify" with XEN 3.0.1 but the 2.6.12-xen kernels that I used all crashed on this hardware in an early stage of booting no matter wich noacpi, noapic, nousb etc. parameters I used. I booted the system about 50-100 times with the help of a serial console with no success. Even with the latest BIOS releases it didn''t work. So I switched to XEN-ustable with success. I was able to boot but my initrd with root on LVM setup didn''t work anymore because of the missing devfs support. What really helped with minimal changes to the base system (still original sarge glibc etc.) was to use a few packages from http://www.backports.org. (udev, initramfs-tools, updated module-init-tools). I''ve switched the DOMU''s to udev too but I need no initrd for the DOMU''s since I compiled a customized 2.6.16.5-xen kernel which I use for DOM0 and DOMU''s. -- __________________________________________________ Ralf Schenk fon (02 41) 9 91 21-0 fax (02 41) 9 91 21-59 rs@databay.de Databay AG Hüttenstraße 7 D-52068 Aachen www.databay.de Databay - einfach machen. _________________________________________________ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users