I can explain the reason for the behavior you are seeing with sunburst chart when using the Cluster -> Host -> Virtual Machine for VMware.
We can skip over the 1st and 2nd system types since they are working fine.
3rd System type: VMware sets a default value of -1 for CPU_LIMIT_MHZ for Virtual Machine. A value of -1 means there is no limit set for the VM. Most VMware administrators do not change the default value. You are seeing N/A and some negative value as a result of this default value. As you have already figured out, CPU_LIMIT_MHZ is not the correct metric to use for size.
Amended 3rd System Type: The short answer to the behavior you are describing is - it is on account of over-subscription due to virtualization. Since the benefit of VMware or virtualization technologies are based on over-subscription, when you look at the data from vCenter, SUM (VM.CPU_MHZ) is likely to be much higher than HOST.CPU_MHZ. In sunburst charts, the presentation calls for the size of the parent to be equal to the size of the sum of the children.
To enable metric consistency between layers of the sunburst chart, we set the HOST.CPU_MHZ = SUM (VM.CPU_MHZ). As you have pointed out, the calculated value of host.size is 10 times larger than the actual size seen in the data which is directly a result of over-subscription.
What's your goal / use case? Perhaps, we could help you pick some other entities and/or metrics that lend themselves better for sunburst chart representation.
are you ok with explanation provided by Jeyashree?
Please let us know.
a phone call / webex is being arranged for next Monday afternoon to discuss the Sunburst with Jeyashree.
It sounds good!
BMC Communities <https://communities.bmc.com/?et=watches.email.thread>
Sunburst configuration problem
reply from David Buchanan<https://communities.bmc.com/people/david.buchanan?et=watches.email.thread> in TrueSight Capacity Optimization - View the full discussion<https://communities.bmc.com/message/813693?et=watches.email.thread#813693>