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

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?