[libvirt] [PATCH v2 0/7] optionally expose disk usage during dumpxml

Eric Blake eblake at redhat.com
Wed Nov 19 14:49:02 UTC 2014


On 11/18/2014 09:42 AM, Daniel P. Berrange wrote:
> On Tue, Nov 18, 2014 at 04:38:49PM +0000, Daniel P. Berrange wrote:
>> On Tue, Nov 18, 2014 at 06:31:46AM -0700, Eric Blake wrote:
>>> v1 was here:
>>> https://www.redhat.com/archives/libvir-list/2014-September/msg01077.html
>>>
>>> This adds the framework for exposing disk of all disks from a single
>>> dumpxml command.  I'm still working on a followup patch to further
>>> list usage of disks in the backing chain, rather than just the
>>> top-level disk, but want to get review started on this code.
>>
>> I'm not really convinced that exposing disk allocation/capacity
>> information in the XML is appropriate. The XML is intended as a
>> representation of the guest hardware API and the host configuration.
>>
>> The disk allocation/capacity info is neither of those things - it
>> is a statistic about the current state of the system. THis is
>> something that we'd usually report via dedicated APIs not the
>> XML.
> 
> eg, I'd expect this data to be reported by either virDomainListGetStats
> or virDomainBlockStatsFlags, not in the XML document. I think this would
> be better for programs wanting to use this data too. They are going to
> want to poll on this information reasonably frequently, so it makes no
> sense to incur the overhead of formatting & parsing the entire domain
> XML which will not be changing, just to get the disk stats which will
> be changing.

Okay, I'll post a v3 that uses virDomainListGetStats as the mechanism
for exposing the information.

-- 
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/20141119/42990ac3/attachment-0001.sig>


More information about the libvir-list mailing list