Some thoughts on enhancing High Availability in oVirt

Perry Myers pmyers at redhat.com
Tue Feb 21 01:42:05 UTC 2012


> Currently CAPE uses deltacloud APIs to start/stop instances.
> 
> The choosing of which host to start the vm is an act of scheduling
> which, in our model, is in the domain of the IAAS platform,  I expect
> the typical start operation would look like:
> 1. cape determines which VMs to start
> 2. cape sends instance start operations to deltacloudd
> 3. deltacloudd sends instance start operations to OE API
> 4. OE starts the vms
> 
> The model we have been operating under is that setup work of the actual
> virtual machine image is done prior to launching.
> 
> Physical resource mapping (such as LUNs or block storage) are again the
> domain of the IAAS platform.
> 
> Note we have had some informal requests to also handle scheduling, but
> would need topology information about the physical resources available
> in order to make those decisions.  Currently there is no "standardized"
> way to determine the topology.  We don't tackle this problem (currently)
> in our implementation.  The project is only focused on HA.

Right, so the path forward can either be:

1. pcmk-cloud operates as described above, offloading VM placement to
   the IAAS platform (oVirt Engine) and oVirt Engine can either:
   a. Continue to do VM placement via it's existing algorithms
   b. Include usage of the Pacemaker Policy Engine specifically to
      handle VM placement but not HA
2. pcmk-cloud is expanded to include VM placement, and incorporates
   add'l policies to do this.  This requires oVirt Engine to:
   a. Expose APIs that allow pcmk-cloud to examine the current
      host/network/storage topologies and utilization in order to make
      the proper choice based on the constraints

I think that model 1 is the better one to go with, and we'll leave IAAS
platforms to do what they do best, which is understand the available
hardware in order to optimally place VMs.  (Just as we do w/ EC2,
OpenStack, Aeolus)

But I also think that 1b is worth exploring as a parallel effort, as
more expressive policy for VM placement may be a good thing and the
Pacemaker library for the PE could do a good job here.

Perry



More information about the Arch mailing list