Open Stack

On Tue, May 24, 2016 at 01:59:17PM -0400, Sean Dague wrote:

Thanks for the summary, Sean.

[...]

> It turns out it works fine because libvirt *actually* seems to take the
> data from cpu_map.xml and do a translation to what it believes qemu will
> understand. On these systems apparently this turns into "-cpu
> Opteron_G1,-pse36"
> (http://logs.openstack.org/29/42529/24/check/gate-tempest-dsvm-multinode-full/5f504c5/logs/libvirt/qemu/instance-0000000b.txt.gz)
> 
> At some point between libvirt 1.2.2 and 1.3.1, this changed. Now libvirt
> seems to be passing our cpu_model directly to qemu, and assumes that as
> a user you will be responsible for writing all the <feature/> stanzas to
> add/remove yourself. When libvirt sends 'gate64' to qemu, this explodes,
> as qemu has no idea what we are talking about.
> http://logs.openstack.org/34/319934/2/experimental/gate-tempest-dsvm-multinode-live-migration/b87d689/logs/screen-n-cpu.txt.gz#_2016-05-24_15_59_12_531

[...]

So, in short, the central issue seems to be this: the custom 'gate64'
model is not being trasnalted by libvirt into a model that QEMU can
recognize.

I could reproduce it with upstream libvirt
(libvirt-1.3.4-2.fc25.x86_64), and filed this bug:

    https://bugzilla.redhat.com/show_bug.cgi?id=1339680 -- libvirt CPU
    driver fails to translate a custom CPU model into something that
    QEMU recognizes

Some discussion from libvirt migration developers (comment #3):

    "So it looks like the whole code which computes the right CPU model
    is skipped. The reason is <domain type='qemu'>. Our code avoids
    comparing guest CPU definition to host CPU for TCG mode (since the
    host CPU is irrelevant in this case). And as a side effect the code
    that would translate the gate64 CPU model into something that is
    supported by QEMU is skipped too."

> So, the existing cpu_map.xml workaround for our testing situation will
> no longer work.

[...]

-- 
/kashyap