<div dir="ltr"><div class="gmail_default" style="font-family:'courier new',monospace">Thanks Steve,</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">

I actually found which extensions the two CPUs had in common and created my own in cpu_map.xml (<a href="http://pastie.org/pastes/8478554/text" target="_blank">http://pastie.org/pastes/8478554/text</a>).  The extensions commented out are ones that I could not find referenced in the cpu_map...  I may try un-commenting them to see what happens :P</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default"><span style="font-family:'courier new',monospace">It is strange... I start up a VM on the new compute node and it is running fine, when I try to do a live migration I get: "</span><font face="courier new, monospace">2013-11-13 16:43:18.063 ERROR nova.virt.libvirt.driver [req-7591a8a0-17ad-4539-b969-6b4a7d156963 43b2e3d7bed64bacab2f69b0cb7ce387 417de5251c804c45baabd0fa2873b43f] CPU doesn't have compatibility." which is odd because I only specified extensions the two CPUs have in common.  Hrmmmm.</font></div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Sam</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Nov 13, 2013 at 3:47 PM, Steve Gordon <span dir="ltr"><<a href="mailto:sgordon@redhat.com" target="_blank">sgordon@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">----- Original Message -----<br>
> From: "Samuel Winchenbach" <<a href="mailto:swinchen@gmail.com">swinchen@gmail.com</a>><br>
> To: <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
> Sent: Wednesday, November 13, 2013 2:57:32 PM<br>
> Subject: [Openstack-operators] New compute node, new libvirt_cpu_mode<br>
><br>
> Hi All.<br>
><br>
> I was wondering what the implications of changing libvirt_cpu_mode from the<br>
> default (host-passthrough) to none might be?   I setup a new compute node<br>
> that has a slightly newer processor model than the other nodes and live<br>
> migration is NOT happy about that.   I have done some reading and<br>
> discovered setting libvirt_cpu_mode=none should help solve the problem.<br>
>  What can I expect if I do this?   I am assuming a slight performance hit<br>
> as the VM will not have access to certain processor extensions.  Here is a<br>
> list of /proce/cpuinfo for two vms (one with =none and the other default).<br>
><br>
> <a href="http://paste.openstack.org/show/52519/" target="_blank">http://paste.openstack.org/show/52519/</a><br>
><br>
> It is clear that the default mode enables more processor extensions.<br>
><br>
> Is there any other way around this problem?<br>
><br>
> Thanks,<br>
> Sam<br>
<br>
</div></div>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.<br>

<br>
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.<br>

<br>
-Steve<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/LibvirtXMLCPUModel" target="_blank">https://wiki.openstack.org/wiki/LibvirtXMLCPUModel</a><br>
</blockquote></div><br></div>