On Wed, Apr 29, 2015 at 10:30:09AM -0600, Eric Blake wrote:
> On 04/29/2015 09:47 AM, Andreas Buschmann wrote:
> > Hello,
> >
> > I have two servers where I can push VMs from one to the other by issuing
> > the command
> >
> > virsh migrate --live --persistent --copy-storage-all --verbose \
> > test6 qemu+ssh://kvmhost2/system
> >
> > on kvmhost1. I can get the VM back by issuing the equivalent command on
> > kvmhost2:
> >
> > virsh migrate --live --persistent --copy-storage-all --verbose \
> > test6 qemu+ssh://kvmhost1/system
> >
> > virsh copies the local data file /data/vm/test6.qcow2 with the
> > filesystem over to the other server.
> >
> >
> > Is there a way to just copy the data file over to the second server,
> > without moving the VM?
> > I want the equivalent of doing these two migrations is sequence, but
> > without moving the VM.
>
> Yes - 'virsh blockcopy' can be used for creating a live copy of storage
> without wasting time copying memory state. That said, blockcopy is
> still waiting for a qemu 2.4 feature of persistent bitmaps before it can
> work with non-transient domains (that is, in order to make the copy
> operation restartable, which is necessary for a persistent domain, we
> need more help from qemu, as well as patches to libvirt to use that new
> qemu feature). So for now, you will have to temporarily undefine your
> domain before doing the blockcopy;
Since I was testing something this morning, here's the quick CLI I
tested with to do a live blockcopy test (this doesn't include the
"--quiesce" step that Eric talks further below):
Assuming you begin with the below chain:
base <-- snap1 (live QEMU)
Performing a 'shallow' blockcopy this way:
$ virsh dumpxml --inactive cirrvm > /var/tmp/cirrvm.xml
$ virsh undefine cirrvm
$ virsh blockcopy cirrvm hda /export/copy.qcow2 \
--wait --verbose --shallow --finish
Block Copy: [100 %]
Successfully copied
$ virsh define /var/tmp/cirrvm.xml
Will result in:
base <-- snap1 (live QEMU)
^
|
'----- copy
Optionally, if you want to pivot the live QEMU to the copy.qocw2, you
can replace the "--finish" flag with "--pivot".
--
/kashyap
> you may also have to manually coordinate quiescing the disks through
> the guest agent if you want your backup to be bootable from a stable
> point in guest I/O (the copy you are creating via migration is
> equivalent to what you get when you yank the power cord; the disk may
> have unflushed pending I/O that you lose, unless you involve the guest
> agent to quiesce data operations).
>
> >
> > The goal is to get a backup copy of a running system onto a second
> > system (kvmhost2). The copy (snapshot) from kvmhost2 can then be
> > copied to a backup server, and can be used for a fast recovery point
> > if kvmhost1 dies.
>
> For that matter, upstream qemu has some patch series that are
> proposing adding automated failover of guests, where you can get even
> more rapid response time for recovering on the backup host when the
> primary host fails (look for COLO on the qemu archives). Again, it
> will need to land in qemu, as well as be wired up in libvirt.
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
