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

On Mon, Dec 22, 2014 at 03:50:58PM -0700, Eric Blake
wrote:
> On 12/22/2014 03:27 PM, Gary R Hook wrote:
> > I am experimenting with the blockcopy command, and after figuring out
> > how to integrate qemu-nbd, nbd-client and
> > dumpxml/undefine/blockcopy/define/et. al. I have one remaining
question:
> > 
> > What's the point?
> 
> 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.
To add to Eric's explanation, I recently wrote a small example about it
here (this was tested with libvirt 1.2.6 & QEMU 2.1):

    http://kashyapc.com/2014/07/06/live-disk-migration-with-libvirt-blockcopy/
> > The "replication" disk file is not, from what I can
ascertain, bootable.
> 
> 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.
I remember a RHEL7 bug you filed for that, Eric,

    https://bugzilla.redhat.com/show_bug.cgi?id=1151629 -- blockcopy
    --keep-overlay ought to have --quiesce option 

Something similar needs to be cloned upstream?

-- 
/kashyap

On 12/23/14 6:17 AM, Kashyap Chamarthy wrote:
> On Mon, Dec 22, 2014 at 03:50:58PM -0700, Eric Blake wrote:
>> On 12/22/2014 03:27 PM, Gary R Hook wrote:
>>> I am experimenting with the blockcopy command, and after figuring
out
>>> how to integrate qemu-nbd, nbd-client and
>>> dumpxml/undefine/blockcopy/define/et. al. I have one remaining
question:
>>>
>>> What's the point?
>>
>> 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.
>
> To add to Eric's explanation, I recently wrote a small example about it
> here (this was tested with libvirt 1.2.6 & QEMU 2.1):
>
>     
http://kashyapc.com/2014/07/06/live-disk-migration-with-libvirt-blockcopy/
I read that article.

Now shut down the domain (post-pivot) which is using the new disk file, 
and start it up, without using a block device. This is the part that no 
one seems to write about, nor do I see that in your example. But thank 
you very much for your help and your articles; very much appreciated.

-- 
Gary R Hook
Senior Kernel Engineer
NIMBOXX, Inc

On 12/23/2014 05:24 PM, Gary R Hook wrote:
> I read that article.
> 
> Now shut down the domain (post-pivot) which is using the new disk file,
> and start it up, without using a block device. This is the part that no
> one seems to write about, nor do I see that in your example. But thank
> you very much for your help and your articles; very much appreciated.
What do you mean by "without using a block device"?  Are you trying to
revert back to the pre-copy file?  Libvirt is supposed to rewrite the
domain XML to reflect the end result of breaking the mirroring (whether
you pivot or abort back to the original), and further starts of the
domain should use the correct current file (which might not be the file
that the earlier domain start used).  If you abort a blockcopy before it
is complete, the destination is useless (incomplete).  If you end a
blockcopy after it reached mirroring phase, the the file that you
abandon (whether the original if you pivoted, or the destination if you
aborted) is a point-in-time snapshot of the disk at the point you quit
the mirroring; this disk snapshot is liable to need fsck and otherwise
have inconsistencies unless you also ensured that guest I/O was stable
before the point of breaking the mirroring (basically, using guest-agent
freezing and thawing around the operation).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org