[Libvirt-cim] What does NumberOfBlocks and ConsumableBlocks in the Xen_Memory class represent?

[Kaitlin Rupert]

Medlyn, Dayne (VSL - Ft Collins) wrote:
> Kaitlin,
> 
> Do you know if I can rely on a standard format for the Revision field in VirtualSystemManagementService class?  Looking at the code I see it is provided as a build variable "-DLIBVIRT_CIM_RV=" that gets set in the acinclude.m4 script. 
> I suppose any of the distributions can label
> this any way they see fit.  

Right - the distros have control over how they wish to set this value.

> So far I have seen:
> 
> SLES11: 0.5.2
> RHEL5.3: 613+

Upstream, we use the changeset and the revision numbers from mercurial. 
The problem the distros face is that that they may be using 0.5.2 as a 
base, but they will have their own patches applied - some from upstream 
libvirt-cim and some from in house.

> 
> Our 0.4.1 build: 590
> Current testing builds: 875
> 
> Any thought on any standard format?  

I don't know of an easy way to force a standard format since its up to 
the distros discretion to change whatever method we go with.

It might be possible to use a combination of the distro package version 
and the Revision values from the VirtualSystemManagementService class.

> Do you know what the build number was for 0.5.1 (somewhere between 590 and 613)?  At the moment I am planning to handle the x.x.x and x\D+ cases.  If anyone has any other thoughts or experiences I am open to them.

0.5.1 is 657  - you can check out the release versions at: 
http://libvirt.org/hg/libvirt-cim/tags

613 is somewhere between 0.4.0 (590) and 0.5.0 (632).

Unfortunately, I'm not coming up with an easy way as to how to handle 
the difference in the distros.  We have to detect the libvirt version, 
which we do using a acinclude.m4 based on the version the distro 
reports.  That might be a more reliable way, but it's less dynamic.

We could add a release attribute to libvirt-cim (in addition to the 
changeset and revision values), but that won't help you with existing 
versions.

> 
> Thanks.
> 
> Dayne
> 
>    
> 
>>> Just for confirmation, does this mean that for anything 0.5.1 and
>> newer I should expect:
>>> -NumberOfBlocks the maximum memory allocated to the guest
>>> -ConsumableBlocks the memory currently assigned to the guest
>>>
>>> And for anything older than 0.5.1 I should expect:
>>>
>>> -NumberOfBlocks the memory currently assigned to the guest
>>> -ConsumableBlocks the maximum memory allocated to the guest
>> Yes, that's correct.  We're one the same page here.  Sorry for the
>> confusing detour there. ;)
>>
>>


-- 
Kaitlin Rupert
IBM Linux Technology Center
kaitlin at linux.vnet.ibm.com