What does NumberOfBlocks and ConsumableBlocks in the Xen_Memory class represent?
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? Thanks for your help. Dayne
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_Memory",DeviceID="rstest_domain/mem",SystemCreationClassName="Xen_ComputerSystem",SystemName="rstest_domain"' -nl localhost:5988/root/virt:Xen_Memory.CreationClassName="Xen_Memory",DeviceID="rstest_domain/mem",SystemCreationClassName="Xen_ComputerSystem",SystemName="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@linux.vnet.ibm.com
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 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? Dayne
-----Original Message----- From: libvirt-cim-bounces@redhat.com [mailto:libvirt-cim- bounces@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@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
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.
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@redhat.com [mailto:libvirt-cim- bounces@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@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
Kaitlin,
Thanks for the correction. It seems were trying to use these
Medlyn, Dayne (VSL - Ft Collins) wrote: 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@redhat.com [mailto:libvirt-cim- bounces@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@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
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.
Correct - that's what the bug is here. A regression was introduced. In 0.4.1: -NumberOfBlocks the memory currently assigned to the guest -ConsumableBlocks the maximum memory allocated to the guest In 0.5.2: -NumberOfBlocks the maximum memory allocated to the guest -ConsumableBlocks the memory currently assigned to the guest 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
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
Ah, my mistake. When I read your previous message, I thought you were talking about the issue above. The values do seem strange. We use the following calculation: NumberOfBlocks = (max_mem * 1024) / BlockSize ConsumableBlocks = (used_mem * 1024) / BlockSize Agreed - NumberOfBlocks is puzzling: (4294967040 / 1024) * 4096 = 17179865088 KB 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. 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:
Kaitlin,
Thanks for the correction. It seems were trying to use these
Medlyn, Dayne (VSL - Ft Collins) wrote: 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@redhat.com [mailto:libvirt-cim- bounces@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@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
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
Kaitlin,
Thanks for the correction. It seems were trying to use these
Medlyn, Dayne (VSL - Ft Collins) wrote: properties correctly and there is something just not right. Using
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
Medlyn, Dayne (VSL - Ft Collins) wrote: the 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
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
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@redhat.com [mailto:libvirt-cim- bounces@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
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
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
values these libvirt- possible 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@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
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.
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
Medlyn, Dayne (VSL - Ft Collins) wrote:
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
Yes, that's correct. We're one the same page here. Sorry for the confusing detour there. ;) -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
Kaitlin, Do you know if I can rely on a standard format for the Revision field in VirtualSystemManagementService class? Looking at the code I see it is provided as a build variable "-DLIBVIRT_CIM_RV=" that gets set in the acinclude.m4 script. I suppose any of the distributions can label this any way they see fit. So far I have seen: SLES11: 0.5.2 RHEL5.3: 613+ Our 0.4.1 build: 590 Current testing builds: 875 Any thought on any standard format? Do you know what the build number was for 0.5.1 (somewhere between 590 and 613)? At the moment I am planning to handle the x.x.x and x\D+ cases. If anyone has any other thoughts or experiences I am open to them. Thanks. Dayne
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
Yes, that's correct. We're one the same page here. Sorry for the confusing detour there. ;)
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
Medlyn, Dayne (VSL - Ft Collins) wrote:
Kaitlin,
Do you know if I can rely on a standard format for the Revision field in VirtualSystemManagementService class? Looking at the code I see it is provided as a build variable "-DLIBVIRT_CIM_RV=" that gets set in the acinclude.m4 script. I suppose any of the distributions can label this any way they see fit.
Right - the distros have control over how they wish to set this value.
So far I have seen:
SLES11: 0.5.2 RHEL5.3: 613+
Upstream, we use the changeset and the revision numbers from mercurial. The problem the distros face is that that they may be using 0.5.2 as a base, but they will have their own patches applied - some from upstream libvirt-cim and some from in house.
Our 0.4.1 build: 590 Current testing builds: 875
Any thought on any standard format?
I don't know of an easy way to force a standard format since its up to the distros discretion to change whatever method we go with. It might be possible to use a combination of the distro package version and the Revision values from the VirtualSystemManagementService class.
Do you know what the build number was for 0.5.1 (somewhere between 590 and 613)? At the moment I am planning to handle the x.x.x and x\D+ cases. If anyone has any other thoughts or experiences I am open to them.
0.5.1 is 657 - you can check out the release versions at: http://libvirt.org/hg/libvirt-cim/tags 613 is somewhere between 0.4.0 (590) and 0.5.0 (632). Unfortunately, I'm not coming up with an easy way as to how to handle the difference in the distros. We have to detect the libvirt version, which we do using a acinclude.m4 based on the version the distro reports. That might be a more reliable way, but it's less dynamic. We could add a release attribute to libvirt-cim (in addition to the changeset and revision values), but that won't help you with existing versions.
Thanks.
Dayne
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 Yes, that's correct. We're one the same page here. Sorry for the confusing detour there. ;)
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
Thanks Kaitlin, I think for now I may just have to base it off the RPM version. It would have been more convenient to get it through the provider, but this will work. Dayne
-----Original Message----- From: libvirt-cim-bounces@redhat.com [mailto:libvirt-cim- bounces@redhat.com] On Behalf Of Kaitlin Rupert Sent: Wednesday, May 20, 2009 3:51 PM To: List for discussion and development of libvirt CIM Subject: Re: [Libvirt-cim] What does NumberOfBlocks and ConsumableBlocks in the Xen_Memory class represent?
Kaitlin,
Do you know if I can rely on a standard format for the Revision field in VirtualSystemManagementService class? Looking at the code I see it is provided as a build variable "-DLIBVIRT_CIM_RV=" that gets set in
Medlyn, Dayne (VSL - Ft Collins) wrote: the acinclude.m4 script.
I suppose any of the distributions can label this any way they see fit.
Right - the distros have control over how they wish to set this value.
So far I have seen:
SLES11: 0.5.2 RHEL5.3: 613+
Upstream, we use the changeset and the revision numbers from mercurial. The problem the distros face is that that they may be using 0.5.2 as a base, but they will have their own patches applied - some from upstream libvirt-cim and some from in house.
Our 0.4.1 build: 590 Current testing builds: 875
Any thought on any standard format?
I don't know of an easy way to force a standard format since its up to the distros discretion to change whatever method we go with.
It might be possible to use a combination of the distro package version and the Revision values from the VirtualSystemManagementService class.
Do you know what the build number was for 0.5.1 (somewhere between 590 and 613)? At the moment I am planning to handle the x.x.x and x\D+ cases. If anyone has any other thoughts or experiences I am open to them.
0.5.1 is 657 - you can check out the release versions at: http://libvirt.org/hg/libvirt-cim/tags
613 is somewhere between 0.4.0 (590) and 0.5.0 (632).
Unfortunately, I'm not coming up with an easy way as to how to handle the difference in the distros. We have to detect the libvirt version, which we do using a acinclude.m4 based on the version the distro reports. That might be a more reliable way, but it's less dynamic.
We could add a release attribute to libvirt-cim (in addition to the changeset and revision values), but that won't help you with existing versions.
Thanks.
Dayne
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 Yes, that's correct. We're one the same page here. Sorry for the confusing detour there. ;)
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
Kaitlin, Just a follow-up. I think your idea of adding a release attribute is a good one. All three values (release, revision, and changeset) would allow a more precise way to pin functionality to builds. I would expect the release to reflect the latest official release number (currently 0.5.2 I believe) with the running revisions and changesets demarking changes off the release, i.e. currently: release 0.5.2, revision 875, changeset: cde25ad65c74+. Thanks for all your help. Dayne
-----Original Message----- From: libvirt-cim-bounces@redhat.com [mailto:libvirt-cim- bounces@redhat.com] On Behalf Of Kaitlin Rupert Sent: Wednesday, May 20, 2009 3:51 PM To: List for discussion and development of libvirt CIM Subject: Re: [Libvirt-cim] What does NumberOfBlocks and ConsumableBlocks in the Xen_Memory class represent?
Kaitlin,
Do you know if I can rely on a standard format for the Revision field in VirtualSystemManagementService class? Looking at the code I see it is provided as a build variable "-DLIBVIRT_CIM_RV=" that gets set in
Medlyn, Dayne (VSL - Ft Collins) wrote: the acinclude.m4 script.
I suppose any of the distributions can label this any way they see fit.
Right - the distros have control over how they wish to set this value.
So far I have seen:
SLES11: 0.5.2 RHEL5.3: 613+
Upstream, we use the changeset and the revision numbers from mercurial. The problem the distros face is that that they may be using 0.5.2 as a base, but they will have their own patches applied - some from upstream libvirt-cim and some from in house.
Our 0.4.1 build: 590 Current testing builds: 875
Any thought on any standard format?
I don't know of an easy way to force a standard format since its up to the distros discretion to change whatever method we go with.
It might be possible to use a combination of the distro package version and the Revision values from the VirtualSystemManagementService class.
Do you know what the build number was for 0.5.1 (somewhere between 590 and 613)? At the moment I am planning to handle the x.x.x and x\D+ cases. If anyone has any other thoughts or experiences I am open to them.
0.5.1 is 657 - you can check out the release versions at: http://libvirt.org/hg/libvirt-cim/tags
613 is somewhere between 0.4.0 (590) and 0.5.0 (632).
Unfortunately, I'm not coming up with an easy way as to how to handle the difference in the distros. We have to detect the libvirt version, which we do using a acinclude.m4 based on the version the distro reports. That might be a more reliable way, but it's less dynamic.
We could add a release attribute to libvirt-cim (in addition to the changeset and revision values), but that won't help you with existing versions.
Thanks.
Dayne
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 Yes, that's correct. We're one the same page here. Sorry for the confusing detour there. ;)
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
Medlyn, Dayne (VSL - Ft Collins) wrote:
Kaitlin,
Just a follow-up. I think your idea of adding a release attribute is a good one. All three values (release, revision, and changeset) would allow a more precise way to pin functionality to builds. I would expect the release to reflect the latest official release number (currently 0.5.2 I believe) with the running revisions and changesets demarking changes off the release, i.e. currently: release 0.5.2, revision 875, changeset: cde25ad65c74+.
Sure - I think it would be useful as well. It would give you a base version and then the revision / changeset can get you a hint of what patches might be included on top of the release. I'll see if I can get that worked up in the next day or two. Just to note - the current release is 0.5.5. Revision 883, changeset 10e45fca47f0.
Thanks for all your help.
Dayne
-----Original Message----- From: libvirt-cim-bounces@redhat.com [mailto:libvirt-cim- bounces@redhat.com] On Behalf Of Kaitlin Rupert Sent: Wednesday, May 20, 2009 3:51 PM To: List for discussion and development of libvirt CIM Subject: Re: [Libvirt-cim] What does NumberOfBlocks and ConsumableBlocks in the Xen_Memory class represent?
Kaitlin,
Do you know if I can rely on a standard format for the Revision field, in VirtualSystemManagementService class? Looking at the code I see it is provided as a build variable "-DLIBVIRT_CIM_RV=" that gets set in
Medlyn, Dayne (VSL - Ft Collins) wrote: the acinclude.m4 script.
I suppose any of the distributions can label this any way they see fit. Right - the distros have control over how they wish to set this value.
So far I have seen:
SLES11: 0.5.2 RHEL5.3: 613+ Upstream, we use the changeset and the revision numbers from mercurial. The problem the distros face is that that they may be using 0.5.2 as a base, but they will have their own patches applied - some from upstream libvirt-cim and some from in house.
Our 0.4.1 build: 590 Current testing builds: 875
Any thought on any standard format? I don't know of an easy way to force a standard format since its up to the distros discretion to change whatever method we go with.
It might be possible to use a combination of the distro package version and the Revision values from the VirtualSystemManagementService class.
Do you know what the build number was for 0.5.1 (somewhere between 590 and 613)? At the moment I am planning to handle the x.x.x and x\D+ cases. If anyone has any other thoughts or experiences I am open to them.
0.5.1 is 657 - you can check out the release versions at: http://libvirt.org/hg/libvirt-cim/tags
613 is somewhere between 0.4.0 (590) and 0.5.0 (632).
Unfortunately, I'm not coming up with an easy way as to how to handle the difference in the distros. We have to detect the libvirt version, which we do using a acinclude.m4 based on the version the distro reports. That might be a more reliable way, but it's less dynamic.
We could add a release attribute to libvirt-cim (in addition to the changeset and revision values), but that won't help you with existing versions.
Thanks.
Dayne
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 Yes, that's correct. We're one the same page here. Sorry for the confusing detour there. ;)
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
participants (2)
-
Kaitlin Rupert -
Medlyn, Dayne (VSL - Ft Collins)