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

[Kaitlin Rupert]

Medlyn, Dayne (VSL - Ft Collins) wrote:
> Hi Kaitlin,
> 
> 
>> Hi Dayne,
>>
>> Let me sort of work backwards here..
>>
>>  > Currently, on this system ConsumableBlocks represent MemTotal or the
>>  > current memory allocated to the guest, even though it is not
>>  > completely accurately representing the free memory on Dom0 that is
>>  > available to new DomUs.  The issue is that between version 0.4.1 and
>>  > 0.5.2 NumberOfBlocks for a Dom0 changed to be MaxInt.  It used to
>>  > match ConsumableBlocks.
> 
> In your original e-mail you said:
> 
> "NumberOfBlocks:   max amount of memory that can be allocated to a guest
>  ConsumableBlocks: current memory allocated to the guest"
> 
> This would mean that for a Dom0, according to the following output:
> 
> $ virsh dominfo Domain
> ...
>  Max memory:     no limit
>  Used memory:    6595584 kB
> ...
> 
> Which seems to indicate that:
> 
> NumberOfBlocks -> no limit (or max int as a reasonable representation)
> ConsumableBlocks -> 6595584 / 4096 blocks
> 
> Which are the values I get in 0.5.2.
> 
> 
>> Correct - that's what the bug is here.  A regression was introduced.
> 
> Arguably, there may be a bug in that maxInt is the "max amount of memory that can be allocated to a guest" for Dom0.  However, libvirt does report that there is "no limit" for Dom0.  
> The change between versions, if it is a regression, is that 0.5.2 is representing "no limit" by maxInt where 0.4.1 represented it as "current memory allocated to ..." Dom0, or the MemTotal on Dom0.
> 
> 
>> In 0.4.1:
>>   -NumberOfBlocks the memory currently assigned to the guest
>>   -ConsumableBlocks the maximum memory allocated to the guest\
> 
> 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.

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

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

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

> 
> 
>> So this should definitely be fixed since we aren't adhering to the
>> definitions in the mof...
>>
>>  > I think there is something else going on here.  As far as I can tell
>>  > the numbers are not swapped.  Here is what I think is going on.  The
>>  > NumberOfBlock x BlockSize equates to about 16TB (not what my system
>>
>> Ah, my mistake.  When I read your previous message, I thought you were
>> talking about the issue above.
> 
> I thought I was talking about the same issue :-).  This is quite confusing.
> 
>> The values do seem strange.  We use the following calculation:
>>
>> NumberOfBlocks = (max_mem * 1024) / BlockSize
>> ConsumableBlocks = (used_mem * 1024) / BlockSize
> 
> For DomU this seems to be what I am seeing.
> 
> 
>> Agreed - NumberOfBlocks is puzzling:
>>    (4294967040 / 1024) * 4096 = 17179865088 KB
>>
> 
> For Dom0 this seems to be a new behavior somewhere between 0.4.1 and 0.5.2.  I am fine with this as there really is not maximum and it appears the max is possibly represented by maxInt (seeing how virsh show it as "no limit").
> 
> 
>> ConsumableBlocks is correct though: (6595584 * 1024) / 4096 = 1648896
>>
>> What does "xm list -l Domain-0" return for memory and maxmem?  I don't
>> have a Xen system with that much mem to test on.
> 
> On the host with libvirt-CIM 0.5.2 / libvirt 0.4.6
> $ xm list -l Domain-0 | grep -i mem
>     (maxmem 16777215)
>     (memory 6441)
>     (shadow_memory 0)
> 
> xm list -l sles11-HVM | grep -i mem
>     (maxmem 1024)
>     (memory 512)
>     (shadow_memory 0)
> 
> On the host with libvirt-CIM 0.4.1 / libvirt
> $ xm list -l Domain-0 | grep -i mem
>     (memory 3621)
>     (shadow_memory 0)
>     (maxmem 3621)
> 
> $ xm list -l target | grep mem
>     (memory 512)
>     (shadow_memory 9)
>     (maxmem 1024)
> 
> 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.

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