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

[Medlyn, Dayne (VSL - Ft Collins)]

Kaitlin,

Thanks for working through this with me.  One last question:

> > Isn't this backwards from your original message?  Or did I just
> misunderstand?  Interestingly, what I see for a DomU with maxmem=1024
> and memory=512 in 0.4.1 is the following:
> 
> In my original message, I was talking about the current implementation
> -
> which would be 0.5.1 and newer.

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

I will need to put this in my code so I can handle both (which I can tell by looking in VirtualSystemManagementService).


> >
> > -ConsumableBlocks=262144
> > -NumberOfBlocks=131072
> > -BlockSize=4096
> >
> > Which is consistent with what you just stated about 0.4.1 and reverse
> of what you said in your original response.
> 
> Correct - sorry for the confusion.  My original response was indicating
> the way the providers behave currently.

No worries.  Thanks for the clarification.


> >
> >> In 0.5.2:
> >>   -NumberOfBlocks the maximum memory allocated to the guest
> >>   -ConsumableBlocks the memory currently assigned to the guest
> >
> > What I see in 0.5.2 for a DomU with maxmem=1024 and memory=512 is:
> >
> > -ConsumableBlocks=131072
> > -NumberOfBlocks=262144
> > -BlockSize=4096
> >
> 
> It looks like the behavior you're seeing is consistent with the last
> email I sent - so we're on the same page, I think. =)

I think so too.  Hopefully we are not both wrong :-).


> >
> > I am pretty new at deciphering MOF files, but if I understand the
> mof, NumberOfBlocks should be the maximum as in the NumberOfBlock x
> BlockSize = total size of
>  > memory (I think this mean maximum memory).  I believe the MOF says
>  > ConsumableBlocks is the number of blocks available for consumption,
> or the actual memory assigned to the guest.  If I understand this
> right,
> it is actually 0.4.1
>  > that is reversed and 0.5.2 contains the correction, yes?
> 
> I reread the mof, and you are correct. So this doesn't appear to be a
> regression at all.

Again, thanks for the confirmation.


> >
> > In either case I am going to have to figure out how to tell if I am
> talking to a 0.4.1 libvirt-CIM or 0.5.2 .. and where the change
> happened .. *sigh* ... so I can handle it appropriately as one of them
> is not right.
> 
> Yes, unfortunately.  You can get the version from the
> VirtualSystemManagementService -

Just what I needed.


> > It looks like you are just reporting what libvirt is telling you ...
> very interesting.  BTW: I don't actually have 16Tb of memory either, I
> only have 8Gb.
> 
> Yes, we pull the value from libvirt and then convert that value in to
> blocks.

> 
> In this case, libvirt is pulling from Xen.  My guess is that the Xen or
> libvirt behavior has changed, which is why you may see the value
> reported change across different versions of Xen / libvirt.

Good to know.


> >
> > It looks like we are honing in on the problem.  Based on everything I
> said above, I believe libvirt-CIM 0.4.1 to be flawed and libvirt-CIM
> 0.5.2 to be correct.  Does this sound about right?  Do you have any
> idea where it may have changed?   Thanks for your patience.
> 
> Yes, agreed.  Here's the change:
> http://libvirt.org/hg/libvirt-cim/rev/2796fd3e2eaa
> 
> We parse the guest XML (essentially virsh dumpxml) to get the various
> attributes of a guest. The problem in 0.4.1 is that we were storing the
> memory values in the wrong structures.
> 
> We later use these struct values in src/Virt_Device.c (starting at line
> 143).  My concern in my original email was that the values were
> reversed
> here as well, but as you pointed out, the values are set correctly.

Thanks again for all the clarification.


Dayne