libvirt-6.5.0 breaks host passthrough migration

Jiri Denemark jdenemar at redhat.com
Mon Jul 13 12:04:25 UTC 2020


On Sat, Jul 11, 2020 at 13:44:19 -0400, Mark Mielke wrote:
> On Sat, Jul 11, 2020 at 6:04 AM Mark Mielke <mark.mielke at gmail.com> wrote:
> 
> > On Fri, Jul 10, 2020 at 7:48 AM Mark Mielke <mark.mielke at gmail.com> wrote:
> >
> >> On Fri, Jul 10, 2020 at 7:14 AM Jiri Denemark <jdenemar at redhat.com>
> >> wrote:
> >>
> >>> The implementation seems to be doing exactly what the commit message
> >>>
> >> says. The migratable=off default should be used only when QEMU does not
> >>> support -cpu host,migratable=on|off, that is only when QEMU is very old.
> >>> Every non-ancient version of libvirt should have the
> >>> QEMU_CAPS_CPU_MIGRATABLE set and thus this code should choose
> >>> migrateble=on default.
> >>>
> >> QEMU_CAPS_CPU_MIGRATABLE only from the <cpu> element? If so, doesn't this
> >> mean that it is not explicitly listed for host-passthrough, and this means
> >> the check is not detecting whether it is enabled or not properly?
> >>
> > Trying to understand what is going on more - I see "migratable" seems to
> > be ok when launching a new machine, but the failure scenario was live
> > migration from 6.4.0 to 6.5.0.
> >
> > Is this because the QEMU_CAPS_CPU_MIGRATABLE was not filled in for 6.4.0,
> > and live migration grabs the capabilities from the source, where the
> > absence of this capability makes it presume an older Qemu in the above code?
> >
> 
> Sorry all - I am having trouble reproducing now. The expected use cases are
> now working.
> 
> Is it possible that the "migratable" flag might have been missing on some
> of the instances, although migration worked fine, and despite having used
> Qemu 4.2 and Qemu 5.0?

When an updated libvirtd which knows about this new capability starts,
it would reprobe all QEMU capabilities (lazily, i.e., once they are
needed). However, if there is a running domain, libvirt will use cached
capabilities probed when the domain was started. I suspect migrating
such domain could be a problem. I'll try to reproduce locally.

Jirka




More information about the libvir-list mailing list