[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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

Attachment: signature.asc
Description: Digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]