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

[Medlyn, Dayne (VSL - Ft Collins)]

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