On 04/30/2012 05:19 PM, Geert Jansen wrote:
> If you touch any of this, please be prepared for the future:
> - Use hyperthreads (exists in kvm today)
> - Add numa topology for guest and the hosts
> - Add Cache info (for VMs too)
> - Add number of DIMMs, especially for VMs, for the upcoming memory hot
> plug feature.
> - BE ready for cpu/cpu/memory hotplug for the hosts and the guests.
Maybe there will be a time where we need this, but for now we just need
the total number of cores. This is important for capacity planning. For
CPU, these capacity planning tools simply add up all the fractional core
usages for all VMs in a cluster, and then it has to be smaller than the
number of total cores in the cluster. So it's important to know the
total number of cores per host.
For a VM, the number of cores is sockets*cores. For a host, it is just
"cores". If you would use socket*cores for a host, you'll get too many.
This isn't obvious and in my view it's a bug.
Simon, I don't really see this as an API breaker by the way. The number
of cores for a host was always cores*sockets even on 3.0, just that
sockets was always equal to 1 (implicitly).
Apologies for replying to my own email, but based on this, my vote would
be for Simon's option #2 (make <host> like <vm>).
I am not so concerned about API breakage as in 3.0 a properly written
client would, in my view, get the "sockets" attribute of the CPU
topology, and set it to "1" if it is not present. If ISVs currently do
not do this, then it's an easy fix to do for them.
Regarding CPUs with different core counts, i think this is very rare and
not something we should worry about initially.
Regards,
Geert