Open Stack

----- Original Message -----
> From: "Samuel Winchenbach" <swinchen at gmail.com>
> To: openstack-operators at lists.openstack.org
> Sent: Wednesday, November 13, 2013 2:57:32 PM
> Subject: [Openstack-operators] New compute node, new libvirt_cpu_mode
> 
> Hi All.
> 
> I was wondering what the implications of changing libvirt_cpu_mode from the
> default (host-passthrough) to none might be?   I setup a new compute node
> that has a slightly newer processor model than the other nodes and live
> migration is NOT happy about that.   I have done some reading and
> discovered setting libvirt_cpu_mode=none should help solve the problem.
>  What can I expect if I do this?   I am assuming a slight performance hit
> as the VM will not have access to certain processor extensions.  Here is a
> list of /proce/cpuinfo for two vms (one with =none and the other default).
> 
> http://paste.openstack.org/show/52519/
> 
> It is clear that the default mode enables more processor extensions.
> 
> Is there any other way around this problem?
> 
> Thanks,
> Sam

If you can identify the Libvirt CPU model that best maps to the lowest common denominator for your cluster (that is includes the CPU flags that are common between the CPUs in your compute nodes) then you can set libvirt_cpu_mode to "custom" and set libvirt_cpu_model to the specific model [1]. This should be Opteron_G3 for the CPU exposed when you used "host-passthrough" in your output.

This will give you better performance than the QEMU baseline CPU and more importantly working live migration but obviously means some of the flags exposed by the newest CPU in the cluster aren't made available to guests.

-Steve

[1] https://wiki.openstack.org/wiki/LibvirtXMLCPUModel