[libvirt-users] non failover equivalent to "virsh migrate --copy-storage-all"
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. 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. Mit freundlichen Gruessen Andreas Buschmann -- Andreas Buschmann [Senior Systems Engineer] net.DE AG
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; 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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 04/29/2015 10:30 AM, Eric Blake wrote:
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; 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).
Another potential solution, with qemu 2.3 and new enough libvirt, is to create an external libvirt snapshot, use external means to copy the primary file while it is read-only, then use active blockcommit to merge the changes made in the meantime back into the primary file. This works without making the domain transient, but also needs manual work for guest-agent queiscing of the file system if you want the backup copy to be at a safe point in guest execution. It is a frequent topic on this list, so there are plenty of archived messages saying the sequence of steps to accomplish this. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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.
participants (3)
-
Andreas Buschmann -
Eric Blake -
Kashyap Chamarthy