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

[Kaitlin Rupert]

Medlyn, Dayne (VSL - Ft Collins) wrote:
> Kaitlin,
> 
> Just a follow-up.  I think your idea of adding a release attribute is a good one.  All three values (release, revision, and changeset) would allow a more precise way to pin functionality to builds.  I would expect the release to reflect the latest official release number (currently 0.5.2 I believe) with the running revisions and changesets demarking changes off the release, i.e. currently: release 0.5.2, revision 875, changeset: cde25ad65c74+.
> 

Sure - I think it would be useful as well.  It would give you a base 
version and then the revision / changeset can get you a hint of what 
patches might be included on top of the release.

I'll see if I can get that worked up in the next day or two.

Just to note - the current release is 0.5.5.  Revision 883, changeset 
10e45fca47f0.

> Thanks for all your help.
> 
> Dayne
> 
> 
>> -----Original Message-----
>> From: libvirt-cim-bounces at redhat.com [mailto:libvirt-cim-
>> bounces at redhat.com] On Behalf Of Kaitlin Rupert
>> Sent: Wednesday, May 20, 2009 3:51 PM
>> To: List for discussion and development of libvirt CIM
>> Subject: Re: [Libvirt-cim] What does NumberOfBlocks and
>> ConsumableBlocks in the Xen_Memory class represent?
>>
>> 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
>>
>> _______________________________________________
>> Libvirt-cim mailing list
>> Libvirt-cim at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvirt-cim
> 
> _______________________________________________
> Libvirt-cim mailing list
> Libvirt-cim at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-cim


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