[libvirt] [PATCH] blockcopy: allow block device destination

[Martin Kletzander]

On Mon, Aug 25, 2014 at 09:55:28AM -0400, Adam Litke wrote:
>On 22/08/14 14:26 -0600, Eric Blake wrote:
>>Ping
>
>Sorry, I thought I'd responded to this.
>
>>On 08/13/2014 02:00 PM, Eric Blake wrote:
>>> To date, anyone performing a block copy and pivot ends up with
>>> the destination being treated as <disk type='file'>.  While this
>>> works for data access for a block device, it has at least one
>>> noticeable shortcoming: virDomainGetBlockInfo() reports allocation
>>> differently for block devices visited as files (the size of the
>>> device) than for block devices visited as <disk type='block'>
>>> (the maximum sector used, as reported by qemu); and this difference
>>> is significant when trying to manage qcow2 format on block devices
>>> that can be grown as needed.
>>>
>>> I still plan to add a virDomainBlockCopy() API that takes the
>>> destination disk as XML, allowing full expressive capability
>>> to copy to a network disk.  But a new API can't be backported,
>>> while a new flag to an existing API can.  So this patch enhances
>>> blockcopy to let the user flag when the resulting XML after the
>>> copy must list the device as type='block'.
>
>Is there any situation where you would not want this behavior?  The
>only thing I can think of is that we need to keep the current behavior
>for backwards compatibility.  If this is the case, then I'd say the
>patch looks reasonable to me.
>
>
>One more question... What happens if this flag is used with a drive of
>type file?  Can we raise an error in that case?
>

I understand it as it makes sense to do that too, so no error should
be reported.  That's because the flag depends on the *target* disk,
not the source one and libvirt can't (easily and reliably) say what
type that should be.

I haven't checked whether it works as it should, but the patch looks
good to me, so ACK from me if my above understanding is correct.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140826/15b87a10/attachment-0001.sig>