Hi, Just setup a guest on a Dom0 (CentoOS 5.2) and would now like to clone or copy that host to another Dom0 (CentOS 5.2). Is that possible ? Guest uses a partition so I can''t copy the image file over. The only thing I''ve found is about migrating a guest between Dom''s. Best Regards, /Arnar Thorarinsson Thessi tolvupostur og vidhengi hans geta innihaldid trunadarupplysingar og er eingongu aetladur theim sem hann er stiladur a. Oheimil medferd tolvuposts thessa og vidhengja hans getur vardad skadabota- og refsiabyrgd samkvaemt logum um fjarskipti. Efni tolvupostsins og vidhengja er a abyrgd sendanda ef thad tengist ekki starfsemi Flugstoda ohf. Ef Thu ert ekki skradur mottakandi og hefur fengid skeytid vegna mistaka, vinsamlegast hafdu strax samband vid sendanda. ------------------------------------------------ This e-mail and its attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Arnar Of course its possible, and there are several options. So your guest is on a partition. A physical partition or a LVM LV? For a LVM LV you can do the following (using the LVM snapshot) without shutting down the domU: lvcreate -s /dev/vg/domU -L1G -n domU_snap mkdir /mnt/domU_snap mount /dev/vg/domU_snap /mnt/domU_snap tar cvjpf /storage/path/domU_snapshot.tbz /mnt/domU_snap lvremove /dev/vg/domU_snap For a physical partition, you should shutdown the domU first (probably pausing is also ok). In this case, you can use the dd command for the backup (check the archives). virt-clone is also an option. Cheers, N. -----Original Message----- From: xen-users-bounces@lists.xensource.com on behalf of Arnar Þórarinsson Sent: Sun 22-Mar-09 12:29 PM To: xen-users@lists.xensource.com Subject: [Xen-users] cloning guests between Dom0''s ? Hi, Just setup a guest on a Dom0 (CentoOS 5.2) and would now like to clone or copy that host to another Dom0 (CentOS 5.2). Is that possible ? Guest uses a partition so I can''t copy the image file over. The only thing I''ve found is about migrating a guest between Dom''s. Best Regards, /Arnar Thorarinsson _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ferreira, N.L. wrote:> For a physical partition, you should shutdown the domU first (probably > pausing is also ok). In this case, you can use the dd command for the > backup (check the archives). virt-clone is also an option.just pausing should be ok, if you mount the DomU filesystem as R/O and disable journalling. -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ferreira, N.L. wrote:>For a LVM LV you can do the following (using the LVM snapshot) >without shutting down the domU: > >lvcreate -s /dev/vg/domU -L1G -n domU_snap >mkdir /mnt/domU_snap >mount /dev/vg/domU_snap /mnt/domU_snap >tar cvjpf /storage/path/domU_snapshot.tbz /mnt/domU_snap >lvremove /dev/vg/domU_snapIs this correct ? I know the LVM snapshot will give you a "point in time" image, but won''t the DomU have unwritten changes in it''s cache - giving you a very unclean filesystem ? -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Simon Hobson wrote:> Ferreira, N.L. wrote: > >> For a LVM LV you can do the following (using the LVM snapshot) >> without shutting down the domU: >> >> lvcreate -s /dev/vg/domU -L1G -n domU_snap >> mkdir /mnt/domU_snap >> mount /dev/vg/domU_snap /mnt/domU_snap >> tar cvjpf /storage/path/domU_snapshot.tbz /mnt/domU_snap >> lvremove /dev/vg/domU_snap > > Is this correct ? I know the LVM snapshot will give you a "point in > time" image, but won''t the DomU have unwritten changes in it''s cache - > giving you a very unclean filesystem ? >You probably want to use kpartx on the snapshot and mount the right partition for backups. However, as you''ll say, you''ll probably come unstuck when you try to mount the file system because it will be corrupt. You need to cooperation of both the OS and any running applications in the domU for this approach to work. A good way to get everything consistent for backing up is to shut down the guest OS, take the snapshot and the re-start the guest OS. Or at least have the guest unmount the file system(s) you''re going to back up before you take the snapshot. Backing up data from a machine (physical or virtual) is surprisingly difficult unless you can enlist the help of the machine. It''s almost always easier to do it from within the machine. jch _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
John Haxby wrote:>>>For a LVM LV you can do the following (using the LVM snapshot) >>>without shutting down the domU: >>> >>>lvcreate -s /dev/vg/domU -L1G -n domU_snap >>>mkdir /mnt/domU_snap >>>mount /dev/vg/domU_snap /mnt/domU_snap >>>tar cvjpf /storage/path/domU_snapshot.tbz /mnt/domU_snap >>>lvremove /dev/vg/domU_snap >> >>Is this correct ? I know the LVM snapshot will give you a "point in >>time" image, but won''t the DomU have unwritten changes in it''s >>cache - giving you a very unclean filesystem ? >> >You probably want to use kpartx on the snapshot and mount the right >partition for backups. However, as you''ll say, you''ll probably >come unstuck when you try to mount the file system because it will >be corrupt. You need to cooperation of both the OS and any running >applications in the domU for this approach to work. A good way to >get everything consistent for backing up is to shut down the guest >OS, take the snapshot and the re-start the guest OS. Or at least >have the guest unmount the file system(s) you''re going to back up >before you take the snapshot. > >Backing up data from a machine (physical or virtual) is surprisingly >difficult unless you can enlist the help of the machine. It''s >almost always easier to do it from within the machine.Just checking I hadn''t missed something ! I agree, it''s a lot easier to just do it from within the client, or to shut the client down. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Mar 23, 2009 at 5:50 PM, Simon Hobson <linux@thehobsons.co.uk> wrote:> Is this correct ? I know the LVM snapshot will give you a "point in time" > image, but won''t the DomU have unwritten changes in it''s cache - giving you > a very unclean filesystem ?Changes in cache - yes. Unclean - yes. Unusable - No. Well, depends on what fs you use, actually :) it will be no worse than a server power failure: If you use ext3 (or any other journaling filesystem that can withstand power failure), then it should be able to replay filesystem journal automatically on mounting to give you a usable filesystem. Regards, Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ferreira, N. L. (Nuno)
2009-Mar-23 18:30 UTC
Re: [Xen-users] cloning guests between Dom0''s ?
I wrote those steps mainly based on : http://www.howtoforge.com/linux_lvm http://www.howtoforge.com/linux_lvm_snapshots From my experience (short), I was able to clone VM''s (SL 47) this way (and backup of course). No problems in particular. Instead of using tar, dd could also be used (but larger files). Is there a better way to do this? I''m just a newbie on this strange world, trying to do my best ;-) Cheers, N. Fajar A. Nugraha wrote:> On Mon, Mar 23, 2009 at 5:50 PM, Simon Hobson <linux@thehobsons.co.uk> wrote: > >> Is this correct ? I know the LVM snapshot will give you a "point in time" >> image, but won''t the DomU have unwritten changes in it''s cache - giving you >> a very unclean filesystem ? >> > > Changes in cache - yes. > Unclean - yes. > Unusable - No. Well, depends on what fs you use, actually :) > > it will be no worse than a server power failure: If you use ext3 (or > any other journaling filesystem that can withstand power failure), > then it should be able to replay filesystem journal automatically on > mounting to give you a usable filesystem. > > Regards, > > Fajar > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >-- =============================================Nuno Ricardo Santos Loureiro da Silva Ferreira NMR Spectroscopy Research Group Bijvoet Center for Biomolecular Research Utrecht University Bloembergen gebouw Padualaan 8, 3584 CH Utrecht The Netherlands P: +31.(0)30.253 9932 F: +31.(0)30.253 2652 E: n.l.ferreira@uu.nl W: http://nmr.chem.uu.nl ============================================= _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ferreira, N. L. (Nuno) wrote:>I wrote those steps mainly based on : > >http://www.howtoforge.com/linux_lvm >http://www.howtoforge.com/linux_lvm_snapshots > >From my experience (short), I was able to clone VM''s (SL 47) this >way (and backup of course). No problems in particular. >Instead of using tar, dd could also be used (but larger files).As Fajar wrote, it''ll work provided you have a robust enough filesystem. The links you provide are fine when the machine making the snapshot is the same as the machine writing files to the volume - because when you read a block off disk, the OS will automatically give you any ''dirty'' block from cache if there is one. Ie, one process writes a chunk of data and it goes into cache as dirty blocks - but has NOT yet been written to disk. Another process goes to read that data, the OS will see that the data is cached, and serve up the cached blocks. So you get a consistent view of the filesystem. When the machine running LVM and making the snapshot (Dom0) is NOT the same as the one running the filesystem (DomU), then the snapshot will be whatever has actually been committed to disk by the DomU rather than the cached version of what will be on the disk when the cache gets written. This can give you a really messed up view of what''s on the disk. In theory, a good journaling filesystem should be able to roll back/roll forward updates to give a consistent view at some point, but personally I would prefer not to have to do this. As Fajar points out, your view of the volume from Dom0 will be very much like the result of pulling the power plug on a server. You can minimise the problem by running "sync" on the guest and creating the snapshot as soon as sync completes - that way, you minimise the amount of unwritten data in the guest''s cache.>Is there a better way to do this? I''m just a newbie on this strange >world, trying to do my best ;-)My personal preference is to do one of the following : 1) Shutdown the guest cleanly, mount it''s filesystem(s) in Dom0, copy the files contained (rsync is my favourite tool for this). It gives by far the cleanest copy as everything will have been closed, no files open, etc - and nothing should change while the copy is in progress. 2) If shutting down the guest isn''t practical, then bring up the machine that you are going to clone into, and use a tool like rsync to copy (across the network) the guest you want to clone - running it from the guest being cloned. You''ll want to exclude non-fs stuff like /dev and /proc, and you''ll probably want to exclude client-specific stuff (eg /etc/network/interfaces on a Debian system). Note that you''ll still have issues with things like database files - you''re clone may well have ''unclean'' files which (depending on activity and database) may be repairable or unusable. Much like cloning a guest - when you clone a database, best to either shut down the database during the copy, or use the database tools to export/copy it. For convenience, once I''d got a basic minimal client image, I then kept this as a template so I can clone it using method 1 to get a running client quickly, and then use method 2 to make it a clone of something else. At the end of the day, there isn''t a "right" way - everyone has their own method that they use - and often it comes down to what tools you are familiar/comfortable with. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hey Simon Uau! "Some" information for me to digest, *but* I understood the cons of my protocol. I was using that protocol to make snapshots of the domU''s from the respective dom0, but sooner or later I was going to clone between dom0''s. Nevertheless, the subject of this thread is "cloning guests between Dom0''s", thus completely agree with your insights. Cheers, N. -----Original Message----- From: xen-users-bounces@lists.xensource.com on behalf of Simon Hobson Sent: Mon 23-Mar-09 7:58 PM To: xen-users@lists.xensource.com Subject: Re: [Xen-users] cloning guests between Dom0''s ? Ferreira, N. L. (Nuno) wrote:>I wrote those steps mainly based on : > >http://www.howtoforge.com/linux_lvm >http://www.howtoforge.com/linux_lvm_snapshots > >From my experience (short), I was able to clone VM''s (SL 47) this >way (and backup of course). No problems in particular. >Instead of using tar, dd could also be used (but larger files).As Fajar wrote, it''ll work provided you have a robust enough filesystem. The links you provide are fine when the machine making the snapshot is the same as the machine writing files to the volume - because when you read a block off disk, the OS will automatically give you any ''dirty'' block from cache if there is one. Ie, one process writes a chunk of data and it goes into cache as dirty blocks - but has NOT yet been written to disk. Another process goes to read that data, the OS will see that the data is cached, and serve up the cached blocks. So you get a consistent view of the filesystem. When the machine running LVM and making the snapshot (Dom0) is NOT the same as the one running the filesystem (DomU), then the snapshot will be whatever has actually been committed to disk by the DomU rather than the cached version of what will be on the disk when the cache gets written. This can give you a really messed up view of what''s on the disk. In theory, a good journaling filesystem should be able to roll back/roll forward updates to give a consistent view at some point, but personally I would prefer not to have to do this. As Fajar points out, your view of the volume from Dom0 will be very much like the result of pulling the power plug on a server. You can minimise the problem by running "sync" on the guest and creating the snapshot as soon as sync completes - that way, you minimise the amount of unwritten data in the guest''s cache.>Is there a better way to do this? I''m just a newbie on this strange >world, trying to do my best ;-)My personal preference is to do one of the following : 1) Shutdown the guest cleanly, mount it''s filesystem(s) in Dom0, copy the files contained (rsync is my favourite tool for this). It gives by far the cleanest copy as everything will have been closed, no files open, etc - and nothing should change while the copy is in progress. 2) If shutting down the guest isn''t practical, then bring up the machine that you are going to clone into, and use a tool like rsync to copy (across the network) the guest you want to clone - running it from the guest being cloned. You''ll want to exclude non-fs stuff like /dev and /proc, and you''ll probably want to exclude client-specific stuff (eg /etc/network/interfaces on a Debian system). Note that you''ll still have issues with things like database files - you''re clone may well have ''unclean'' files which (depending on activity and database) may be repairable or unusable. Much like cloning a guest - when you clone a database, best to either shut down the database during the copy, or use the database tools to export/copy it. For convenience, once I''d got a basic minimal client image, I then kept this as a template so I can clone it using method 1 to get a running client quickly, and then use method 2 to make it a clone of something else. At the end of the day, there isn''t a "right" way - everyone has their own method that they use - and often it comes down to what tools you are familiar/comfortable with. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users