Re: [libvirt-users] Using virsh blockcopy -- what's it supposed to accomplish?

On 12/22/2014 03:27 PM, Gary R Hook wrote: Among other uses, live storage migration. Let's say you are running on a cluster, where your VM is running locally but was booted from network-accessed storage. You don't want any guest downtime, but you want to have the faster performance made possible by accessing local storage instead of the network-accessed storage. virsh blockcopy can be used to change qemu's notion of where the active layer of the disk lives without any guest time, by copying then pivoting to a local file. Correct in the current implementation, if you don't manually freeze guest I/O prior to the point where you abort the copy (whether you do a straight abort, leaving the copy as the point in time, or whether you do a pivot, leaving the original as the point in time). But I would like to add a --quiesce option to blockcopy, similar to what is already available for snapshot-create --quiesce. The idea is that just before breaking sync, you tell the guest to freeze all I/O, so that when you do break sync, the disk you are no longer using _is_ a consistent image (and depending on how well your guest is able to freeze I/O, it may well be bootable). But until that is implemented, you can use 'virsh domfsfreeze' as the manual access to freezing guest I/O, if you have new enough qemu and also have qemu-guest-agent wired up in your guest. How is it not usable? When you break sync at the conclusion of a blockcopy, the image that you no longer use is an accurate snapshot of the state of the disk at the time you broke sync; but whether or not that is useful to a guest depends on how much influence unflushed I/O that was still in guest memory at the time you broke sync will have on your data. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org