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