[Engine-devel] CPU topology in the API

Dor Laor dlaor at redhat.com
Mon Apr 30 11:43:45 UTC 2012


On 04/30/2012 02:37 PM, Simon Grinberg wrote:
> Hi list,
>
> The current status is that though they look the same, CPU topology for hosts and VMs differ.
>
> In both you have
>      <topology cores="N" sockets="Y"/>
>
> for hosts: Cores = Total cores on the host, Y=number of sockets
> for VMs: Cores = Cores per socket, Y=number of sockets
>
> This means that for a hosts that has 4 sockets with 8 cores per socket the topology will be presented as:
>      <topology cores="32" sockets="4"/>
> While for VM with the same requested topology will show:
>      <topology cores="8" sockets="4"/>
>
> I think they should not be different to avoid confusion but:
>
> * The information we displayed for the host can't count on the fact that cores are
> distributed evenly across sockets, because theoretically a host could contain
> several different CPUs, so it can't be displayed as a multiplication.

Isn't that rare to not-exist in the standard case?

> * On the other hand changing the VM topology will break the API though it will make it aligned both with hosts and with the 'New VM' dialogue in the UI.
>
> For oVirt 3.x it may be that nothing can be changed however for oVirt it is allowed in theory to break the API (a bit :)) so the options as I see it are:
>
> 1. Don't touch, leave the confusion.
> 2. Make host align to VMs with the risk that on some hosts this may be a bit misleading - should be rare.
> 3. Make host topology looks like VM but allow multiple CPU topologies in the CPUs sub collection of the host.
>     (This also requires change in VDSM API)
> 4. Align VMs to Hosts
>
> I would go for 4 or 2
> Current CPU topology for the hosts is a new commit, thus it may be allowed to change it now since no one is using it yet. This works in favour of 2. In any case only 3 discloses all the information in all possible cases.
>
>
> Thoughts?

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.

>
>
> Thanks,
> Simon.
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel




More information about the Devel mailing list