[Libvirt-cim] What does NumberOfBlocks and ConsumableBlocks in the Xen_Memory class represent?
Medlyn, Dayne (VSL - Ft Collins)
dayne.medlyn at hp.com
Fri May 15 04:36:05 UTC 2009
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, 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?
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.
Dayne
>
> > has - my system only has 8GB). If you look at virsh dominfo Domain-
> 0
> > on my box I get:
> >
> > Max memory: no limit
> > Used memory: 6595584 kB
> >
> > If NumberOfBlocks is MaxInt (of some sort) than this would make some
> sort of sense and ConsumableBlocks contains the correct value. It is a
> little bit misleading since processes in Dom0 take memory away from
> what
> can be allocated to a DomU. This is evident from this /proc/meminfo
> snippet:
> >
> > MemTotal: 6595584 kB
> > MemFree: 5940684 kB
> > Buffers: 16112 kB
> > Cached: 264716 kB
> > SwapCached: 0 kB
> > Active: 138332 kB
> > Inactive: 216032 kB
> > SwapTotal: 2626544 kB
> > SwapFree: 2626544 kB
> > Dirty: 436 kB
> > ...
> > VmallocTotal: 34359738367 kB
> > VmallocUsed: 267184 kB
> > VmallocChunk: 34359470859 kB
> > DirectMap4k: 8066284 kB
> > DirectMap2M: 0 kB
> >
> >
> > The current WBEM values:
> >
> > -ConsumableBlocks=1648896
> > -NumberOfBlocks=4294967040
> > -BlockSize=4096
>
>
> Medlyn, Dayne (VSL - Ft Collins) wrote:
> >> Medlyn, Dayne (VSL - Ft Collins) wrote:
> >>> Kaitlin,
> >>>
> >>> Thanks for the correction. It seems were trying to use these
> >> properties correctly and there is something just not right. Using
> the
> >> same wbemcli command I get:
> >>> -SystemCreationClassName="Xen_ComputerSystem"
> >>> -SystemName="Domain-0"
> >>> -CreationClassName="Xen_Memory"
> >>> -DeviceID="Domain-0/mem"
> >>>
> >>> -ConsumableBlocks=1717760
> >>> -NumberOfBlocks=4294967040
> >>> -BlockSize=4096
> >> Yes, that's definitely a bug. The values for ConsumableBlocks and
> >> NumberOfBlocks should be swapped. I'd hoped to have a bugfix out
> >> today,
> >> but it looks like it'll be tomorrow.
> >
> >
> > 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 has
> - my system only has 8GB). If you look at virsh dominfo Domain-0 on my
> box I get:
> >
> > Max memory: no limit
> > Used memory: 6595584 kB
> >
> > If NumberOfBlocks is MaxInt (of some sort) than this would make some
> sort of sense and ConsumableBlocks contains the correct value. It is a
> little bit misleading since processes in Dom0 take memory away from
> what can be allocated to a DomU. This is evident from this
> /proc/meminfo snippet:
> >
> > MemTotal: 6595584 kB
> > MemFree: 5940684 kB
> > Buffers: 16112 kB
> > Cached: 264716 kB
> > SwapCached: 0 kB
> > Active: 138332 kB
> > Inactive: 216032 kB
> > SwapTotal: 2626544 kB
> > SwapFree: 2626544 kB
> > Dirty: 436 kB
> > ...
> > VmallocTotal: 34359738367 kB
> > VmallocUsed: 267184 kB
> > VmallocChunk: 34359470859 kB
> > DirectMap4k: 8066284 kB
> > DirectMap2M: 0 kB
> >
> >
> > The current WBEM values:
> >
> > -ConsumableBlocks=1648896
> > -NumberOfBlocks=4294967040
> > -BlockSize=4096
> >
> > 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. I don't think there is an issue and I can work with
> this now that I understand it.
> >
> >
> > As you point out below, I am probably not going to be able to get the
> information I want out of Xen_MemoryPool.
> >
> > Thanks for your help and insight.
> >
> >
> > Dayne
> >
> >
> >
> >
> >
> >>> One difference I did notice is that we are trying to use these
> values
> >> from Dom0 to determine the amount of available memory for guests to
> >> use. Perhaps for Dom0 these values just map differently.
> >>
> >>
> >>> My objective is to identify how much memory is available on the
> >> hypervisor that can be allocated to new guests. Looking more
> closely,
> >> I wonder if we should be using Xen_MemoryPool somehow to do this
> >> instead. What is the relationship between the Capacity and Reserved
> >> properties? I have not quite been able to make sense out of what
> these
> >> values mean. What I have noticed is that a host with no defined
> guests
> >> starts with Reserved smaller than Capacity:
> >>> -PoolID="MemoryPool/0"
> >>> -Primordial=FALSE
> >>> -Capacity=8385536
> >>> -Reserved=8064748
> >>> -ResourceType=4
> >>> -OtherResourceType=
> >>> -ResourceSubType=
> >>> -AllocationUnits="KiloBytes"
> >>>
> >>> As guests are create and start the Reserved count increases and
> grows
> >> beyond the capacity. I am not quite sure how to make use of this
> >> information. Do you have any insights?
> >>
> >> The Capacity value is the memory value libvirt reports for the host
> >> (you'd also get this value if you use: virsh nodeinfo).
> >>
> >> The Reserved value is the some of all the memory that is currently
> >> allocated to the guests on the system (as reported by libvirt).
> This
> >> includes guests that aren't running, which is why you are seeing the
> >> value grow beyond capacity.
> >>
> >> We don't represent the host capabilities, but in the case of Xen,
> you
> >> can get around that by pulling some things from Dom0.
> >>
> >> However, using Dom0's attribute may not give you the full picture
> >> you're
> >> looking for. I would suggest taking a look at a provider set that
> >> represents the host information. Something like the sblim-base
> >> providers should this info.
> >>
> >>>
> >>> Dayne
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: libvirt-cim-bounces at redhat.com [mailto:libvirt-cim-
> >>>> bounces at redhat.com] On Behalf Of Kaitlin Rupert
> >>>> Sent: Wednesday, May 13, 2009 7:10 PM
> >>>> To: List for discussion and development of libvirt CIM
> >>>> Subject: Re: [Libvirt-cim] What does NumberOfBlocks and
> >>>> ConsumableBlocks in theXen_Memory class represent?
> >>>>
> >>>> Medlyn, Dayne (VSL - Ft Collins) wrote:
> >>>>> All,
> >>>>>
> >>>>> I am trying to understand the use of NumberOfBlocks and
> >>>> ConsumableBlocks in the Xen_Memory class, specifically for the Xen
> >>>> host.
> >>>>> What I have noticed is that between libvirt-cim-0.4.1 and
> libvirt-
> >>>> cim-0.5.2 the values for NumberOfBlock is now different than
> >>>> ConsumableBlocks and
> >>>> > much larger than the physical memory installed on the system.
> >>>>> Is it the case that NumberOfBlocks represents the maximum
> possible
> >>>> blocks for the hardware,
> >>>> > or some such number ConsumableBlocks is the memory that is
> >>>>> actually installed in the system? On my system, however,
> >>>> NumberOfBlocks reports 16TB where /proc/meminfo
> >>>>> reports 32Tb for VmallocTotal. In short, should I be using
> >>>> ConsumableBlocks to determine the total physical memory on the
> >> system?
> >>>>
> >>>> Hi Dayne,
> >>>>
> >>>> It looks like there is a bug here. Currently, the providers use
> the
> >>>> following representation:
> >>>>
> >>>> NumberOfBlocks: max amount of memory that can be allocated to a
> >> guest
> >>>> ConsumableBlocks: current memory allocated to the guest
> >>>>
> >>>> However, these values should be reversed based on the attribute
> >>>> definitions.
> >>>>
> >>>> Here's an example using one of the guests on my system:
> >>>>
> >>>> # virsh dominfo rstest_domainId: -
> >>>> Name: rstest_domain
> >>>> UUID: 746de06d-cb45-4efd-bc18-bf91d10bec84
> >>>> State: shut off
> >>>> CPU(s): 1
> >>>> Max memory: 131072 kB
> >>>> Used memory: 130048 kB
> >>>> Autostart: disable
> >>>>
> >>>> We take the max and used memory values libvirt reports and then
> >> convert
> >>>> them based on the block size.
> >>>>
> >>>> # wbemcli gi
> >>>>
> >>
> 'http://localhost:5988/root/virt:Xen_Memory.CreationClassName="Xen_Memo
> >>
> ry",DeviceID="rstest_domain/mem",SystemCreationClassName="Xen_ComputerS
> >>>> ystem",SystemName="rstest_domain"'
> >>>> -nl
> >>>>
> >>
> localhost:5988/root/virt:Xen_Memory.CreationClassName="Xen_Memory",Devi
> >>
> ceID="rstest_domain/mem",SystemCreationClassName="Xen_ComputerSystem",S
> >>>> ystemName="rstest_domain"
> >>>> <snip>
> >>>>
> >>>> -TransitioningToState=12
> >>>> -SystemCreationClassName="Xen_ComputerSystem"
> >>>> -SystemName="rstest_domain"
> >>>> -CreationClassName="Xen_Memory"
> >>>> -DeviceID="rstest_domain/mem"
> >>>>
> >>>> <snip>
> >>>>
> >>>> -BlockSize=4096
> >>>> -NumberOfBlocks=32768
> >>>> -ConsumableBlocks=32512
> >>>>
> >>>> <snip>
> >>>> --
> >>>> Kaitlin Rupert
> >>>> IBM Linux Technology Center
> >>>> kaitlin at linux.vnet.ibm.com
> >>>>
> >>>> _______________________________________________
> >>>> Libvirt-cim mailing list
> >>>> Libvirt-cim at redhat.com
> >>>> https://www.redhat.com/mailman/listinfo/libvirt-cim
> >>> _______________________________________________
> >>> Libvirt-cim mailing list
> >>> Libvirt-cim at redhat.com
> >>> https://www.redhat.com/mailman/listinfo/libvirt-cim
> >>
> >> --
> >> Kaitlin Rupert
> >> IBM Linux Technology Center
> >> kaitlin at linux.vnet.ibm.com
> >>
> >> _______________________________________________
> >> Libvirt-cim mailing list
> >> Libvirt-cim at redhat.com
> >> https://www.redhat.com/mailman/listinfo/libvirt-cim
> >
> > _______________________________________________
> > Libvirt-cim mailing list
> > Libvirt-cim at redhat.com
> > https://www.redhat.com/mailman/listinfo/libvirt-cim
>
>
> --
> Kaitlin Rupert
> IBM Linux Technology Center
> kaitlin at linux.vnet.ibm.com
>
> _______________________________________________
> Libvirt-cim mailing list
> Libvirt-cim at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-cim
More information about the Libvirt-cim
mailing list