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

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+.

Thanks for all your help. Dayne > -----Original Message----- > From: libvirt-cim-bounces(a)redhat.com [mailto:libvirt-cim- > bounces(a)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(a)linux.vnet.ibm.com > > _______________________________________________ > Libvirt-cim mailing list > Libvirt-cim(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvirt-cim _______________________________________________ Libvirt-cim mailing list Libvirt-cim(a)redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim