[nova] "Migrating" ComputeNode within ComputeHost / vmwareapi ComputeNode per ESXi
fabian.wiesel at sap.com
Wed Sep 15 07:08:40 UTC 2021
I am looking at adding the option for the vmwareapi driver to expose the individual ESXi hosts.
A compute-host would represent a cluster in vsphere, and each ESXi-host within a cluster would be a ComputeNode.
The main question here is, how to handle a hypervisor initiated change of the compute-node and if the community is open to extending the compute-driver interface for such a use-case.
The secondary one is, if there is interest in having the upstream vmwareapi driver getting this functionality.
* What are we trying to solve by that?
Our users are asking for that feature, because they want to know, if a payload of two VMs runs on the same physical host, as the performance characteristics are quite different.
We also gain there from an operational and code perspective:
- Nova would become aware of the actual resources per ESXi host instead of the aggregated ones.
- Resources could also be more faithfully represented in the resource-tree (e.g., shared storage as an aggregate).
- Capabilities, (cpu-flags, architecture,… ), Numa topology, and even small things like up-time can be faithfully reflected on a per-host basis.
- The internal scheduling decisions in the driver for ephemeral storage and compute (for live-migration) can be handled by standard placement & nova scheduling.
* Why do we need to change the driver interface?
Main problem here is that VSphere might migrate a VM between two ESXi-hosts for various reasons.
So, the driver would need a way to communicate such a change somehow.
But even if we disable all kind of migrations on VMware side, we still need a way to migrate the
VMs from the single compute-node for the whole cluster to the compute nodes for each individual ESXi-hosts.
* Proposed Driver API Change
The Compute-Manager is currently periodically polling the driver with
ComputeDriver.get_info(self, instance, use_cache)
which returns an InstanceInfo, which is essentially only the power-state.
Adding two new optional fields to InstanceInfo could allow the driver to inform the manager about
- the current compute-node
- the compute-node the VM is migrated to
This allows the Compute-Manager to take care of updating the node field and the resource-allocations accordingly.
Additionally, we can notify the manager over Instance lifecycle events, allowing for a faster reflection of a compute-node change.
The lifecycle events could be
Or one could generalize the current life-migration events to include also such compute-node changes.
I am looking forward for your feedback.
More information about the openstack-discuss