[libvirt] virDomainGetBlockInfo meanings

[Eric Blake]

On 12/16/2014 03:16 AM, Daniel P. Berrange wrote:
> On Mon, Dec 15, 2014 at 05:29:14PM -0700, Eric Blake wrote:
>> I'm really struggling with how to interpret the virDomainBlockInfo
>> struct, and think that we may want to consider the current behavior
>> buggy and offer improved behavior going forward.
>>

>>
>> I interpret this to mean that 'capacity' is the size that the guest
>> sees, that 'allocation' is how much host space is required to represent
>> that to the guest, and 'physical' is the size of the container on the host.
>>

>>
>> Can anyone give a reason why changing semantics of 'physical' and
>> 'allocation' as mentioned above would negatively break backwards
>> compatibility, rather than being considered a bug fix?
> 
> You don't mention the equivalent virStorageVolInfo struct for the
> storage drivers above. This has a capacity & allocation attribute.

Right now, 'capacity' for virStorageVolInfo is always the size the guest
will see (matching how we use 'capacity for virDomainBlockInfo), and
'allocation' of a qcow2 file is probably closer to what I'm using
'physical' for (that is, it appears to be the file size).  I guess where
I'd like to go with this is expand virStorageVolInfo to add 'physical',
and then have the same distinction (being able to tell both how much
space the host file would claim if fully allocated, and how much space
it is actually using thanks to holes).  I guess I have more patches to
write to make things consistent before the release at the end of January!

> 
> So I think it is important that we keep capacity & allocation having
> the same meanings across both.

I agree.  One of the problems with qcow2 images on block devices is that
qemu-img does NOT give us highest-extent-written information (what I'm
calling 'allocation'), so on a storage pool looking at LVM partitions
that contain qcow2-formatted images, the storage code is currently
reporting 'allocation' as the block device size, but that's more what I
term 'physical'; on the other hand, until qemu is patched to give us
highest-extent-written details, 'physical' and 'allocation' will be the
same for such images.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 539 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20141216/ec40c2ab/attachment-0001.sig>