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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
