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

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