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

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:

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

> 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

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,

that is reversed and 0.5.2 contains the correction, yes?

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.

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

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.