Open Stack

Thanks Steve,

I actually found which extensions the two CPUs had in common and created my
own in cpu_map.xml (http://pastie.org/pastes/8478554/text).  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

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: "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.

Sam


On Wed, Nov 13, 2013 at 3:47 PM, Steve Gordon <sgordon at redhat.com> wrote:

> ----- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20131113/a6bb8718/attachment.html>