Allow specification of the libvirt guest CPU model per host

Currently Nova does not configure any CPU model for libvirt
guests. This is sub-optimal because the default KVM CPU
model has changed a number of times, and more importantly
VMs are not able to take advantage of many performance
features in newer CPUs. To get a consistent CPU model exposed
to the guest and maximize performance of VMs in the cloud,
explicit specification of CPU models per host is desirable.

This change adds a new Nova config flag:

  libvirt_cpu_mode = host-model|host-passthrough|custom

Where

  * host-model == configure a model that matches the features
                  available in the host CPU

  * host-passthrough == passthrough the host CPU precisely
                        with no change at all

  * custom == configure a specific named CPU model

If the 'custom' mode is used, then the additional flag
is available to choose the model:

  libvirt_cpu_model = <one of the names from /usr/share/libvirt/cpu_model.xml>

eg

  libvirt_cpu_model = core2duo

If specifying a custom CPU model, it is wise to choose one that is
capable of running on all the various different Nova hosts in the
cloud. That said, libvirt will enforce compatibility at time of
starting or migrating guests & refuse the operation if required.

If using either the host-model or host-passthrough modes, and use
of live migration is desired, admins should ensure that all hosts
have a homogeneous CPU model. If hosts have a hetergeneous CPU
models, then a custom named CPU model is a better choice

This configuration only works for libvirt >= 0.9.10, due to the
use of the 'mode' attribute on the <cpu> element for configuring
host models.

Fixes: bug #1003373
Implements: blueprint libvirt-xml-cpu-model
Change-Id: I90ce78d7e29bd0d563e3bc547b7cc5d64dd9496e
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Merge "Allow specification of the libvirt guest CPU model per host"
Add multi-process support for API services

Implements blueprint multi-process-api-service

This is based on Huang Zhiteng's patch.

This patch adds support for running services as multiple processes. This
is primarily intended to be used with the API service as a way to provide
more concurrency than eventlet can sometimes provide.

A SIGTERM or SIGINT signal will cause the parent process to gracefully
terminate the child processes, allowing them to finish processing the
requests currently being processed. The parent will wait for the
children to finish before exiting.

Change-Id: Ie6d6802626eb42d5e64c4167be363fbf6cea2a1b
Implement blueprint ec2-id-compatibilty.

Instance ids are used by the ec2 layer to create ec2-ids. This
currently uses the id column in the instances table. This patch
creates a new mapping table for ec2-ids. This decouples the ec2
layer from needing direct access to the instances table so that
it can eventually be pulled out if necessary. It also matches the
way that the ec2 layer maps image, volume, and snaphsot ids.
Finally, it allows us to eventually remove the id column from
the instances table and only have one canonical id (uuid) to
refer to instances.

Change-Id: I02ad9fad37e6a04675543398f686351634bc1bb9
Merge "Add multi-process support for API services"