On Mon, Aug 25, 2014 at 09:55:28AM -0400, Adam Litke wrote:
On 22/08/14 14:26 -0600, Eric Blake wrote:PingSorry, 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
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list