RE: [Libvirt-cim] What does NumberOfBlocks and ConsumableBlocks in the Xen_Memory class represent?
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