<div dir="ltr"><div dir="ltr">On Fri, Jul 10, 2020 at 7:14 AM Jiri Denemark <<a href="mailto:jdenemar@redhat.com">jdenemar@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Jul 05, 2020 at 12:45:55 -0400, Mark Mielke wrote:<br>> With 6.4.0, live migration was working fine with Qemu 5.0. After trying out<br>
> 6.5.0, migration broke with the following error:<br>
> <br>
> libvirt.libvirtError: internal error: unable to execute QEMU command<br>
> 'migrate': State blocked by non-migratable CPU device (invtsc flag)<br>
<br>
Could you please describe the reproducer steps? For example, was the<br>
domain you're trying to migrate already running when you upgrade libvirt<br>
or is it freshly started by the new libvirt?<br></blockquote><div><br></div><div><br></div><div>The original case was:</div><div><br></div><div>1) Machine X running libvirt 6.4.0 + qemu 5.0</div><div>2) Machine Y running libvirt 6.5.0 + qemu 5.0</div><div>3) Live migration from X to Y works. Guest appears fine.</div><div>4) Upgrade Machine X from libvirt 6.4.0 to 6.5.0 and reboot.</div><div>5) Live migration from Y to X fails with the message shown.<br></div><div><br></div><div>In each case, live migration was done with OpenStack Train directing libvirt + qemu.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And it would be helpful to see the <cpu> element as shown by virsh<br>
dumpxml before you try to start the domain as well as the QEMU command<br>
line libvirt used to start the domain (in<br>
/var/log/libvirt/qemu/$VM.log).<br></blockquote><div><br></div><div>The <cpu> element looks like this:</div><div><br></div><div><font face="monospace">  <cpu mode='host-passthrough' check='none'><br>    <topology sockets='1' dies='1' cores='4' threads='2'/><br>  </cpu><br></font></div><div><br></div><div>The QEMU command line is very long, and includes details I would avoid publishing publicly unless you need them. The "-cpu" portion is just:</div><div><br></div><div><font face="monospace">    -cpu host<br></font></div><div><br></div><div>The QEMU command line itself is generated from libvirt, which is directed by OpenStack Train.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> commit 201bd5db639c063862b0c1b1abfab9a9a7c92591<br>
> Author: Jiri Denemark <<a href="mailto:jdenemar@redhat.com" target="_blank">jdenemar@redhat.com</a>><br>
> Date:   Tue Jun 2 15:34:07 2020 +0200<br>
> <br>
>     qemu: Fill default value in //cpu/@migratable attribute<br>
> <br>
>     Before QEMU introduced migratable CPU property, "-cpu host" included all<br>
>     features that could be enabled on the host, even those which would block<br>
>     migration. In other words, the default was equivalent to migratable=off.<br>
>     When the migratable property was introduced, the default changed to<br>
>     migratable=on. Let's record the default in domain XML.<br>
> <br>
>     Signed-off-by: Jiri Denemark <<a href="mailto:jdenemar@redhat.com" target="_blank">jdenemar@redhat.com</a>><br>
>     Reviewed-by: Michal Privoznik <<a href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a>><br>
> <br>> Before this change, qemu was still being launched with "-cpu host", which<br>
> for any somewhat modern version of qemu, defaults to migratable=on. The<br>
> above comment acknowledges this, however, the implementation chooses the<br>
> pessimistic and ancient (and no longer applicable!) value of migratable=off:<br>
> <br>
> +    if (qemuCaps &&<br>
> +        def->cpu->mode == VIR_CPU_MODE_HOST_PASSTHROUGH &&<br>
> +        !def->cpu->migratable) {<br>
> +        if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_CPU_MIGRATABLE))<br>
> +            def->cpu->migratable = VIR_TRISTATE_SWITCH_ON;<br>
> <br>
> *+        else if (ARCH_IS_X86(def->os.arch))+<br>
>  def->cpu->migratable = VIR_TRISTATE_SWITCH_OFF;*<br>
> +    }<br>
<br>
The implementation seems to be doing exactly what the commit message<br>
says. The migratable=off default should be used only when QEMU does not<br>
support -cpu host,migratable=on|off, that is only when QEMU is very old.<br>
Every non-ancient version of libvirt should have the<br>
QEMU_CAPS_CPU_MIGRATABLE set and thus this code should choose<br>
migrateble=on default.<br></blockquote><div><br></div><div>I wasn't sure what QEMU_CAPS_CPU_MIGRATABLE represents. I initially suspected what you are saying, but since it apparently did not work the way I expected, I then presumed it does not work the way I expected. :-)</div><div><br></div><div>Is 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?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I think it is not a requirement for "migratable=XXX" to be explicit in<br>
> libvirt. However, if there is some reason I am unaware of, and it is<br>
> important for libvirt to know, then I think it is important for libvirt to<br>
> find out the authoritative state rather than guessing.<br>
Explicit defaults are always better for two reasons: they are visible to<br>
users and they don't silently change.<br>
</blockquote></div><div><br></div><div>I think it can go either way. There is also convention over configuration as a competing principle. However, I also prefer explicit. Just, it needs to be correct, otherwise explicit can be very bad, as it seems in my case. :-)</div><div><br></div><div>Thanks,</div><div><br></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Mark Mielke <<a href="mailto:mark.mielke@gmail.com" target="_blank">mark.mielke@gmail.com</a>><br><br></div></div>