efd7ac1344
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>
The Choose Your Own Adventure README for Nova
You have come across a cloud computing fabric controller. It has identified itself as "Nova." It is apparent that it maintains compatibility with the popular Amazon EC2 and S3 APIs.
To monitor it from a distance: follow @openstack on twitter.
To tame it for use in your own cloud: read http://docs.openstack.org
To study its anatomy: read http://nova.openstack.org
To dissect it in detail: visit http://github.com/openstack/nova
To taunt it with its weaknesses: use http://bugs.launchpad.net/nova
To watch it: http://jenkins.openstack.org
To hack at it: read HACKING
To cry over its PEP-8 problems: http://jenkins.openstack.org/job/gate-nova-pep8/violations