[openstack-dev] [gate] [nova] live migration, libvirt 1.3, and the gate
kchamart at redhat.com
Wed May 25 15:42:04 UTC 2016
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
> 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.
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
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
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.
More information about the OpenStack-dev