Open Stack

Hi,

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 
- EVENT_LIFECYCLE_COMPUTE_NODE_MIGRATION_STARTED
- EVENT_LIFECYCLE_COMPUTE_NODE_MIGRATION_COMPLETED
Or one could generalize the current life-migration events to include also such compute-node changes.

I am looking forward for your feedback.

Cheers,
  Fabian