<div dir="ltr">Hi all:<div><br></div><div>Any thoughts on this, or not time enough to look?</div><div><br></div><div>I'm trying to decide what the right solution is on my end to deal with this breaking change, before more widely deploying it. If I know what the fix will be, I would like to align my strategy against it. Or, if we discuss and the libvirt team disagrees with my analysis, then I will have to decide whether to enable some sort of conversion mechanism to safely migrate machines from libvirt-6.4.0 and before, to libvirt-6.5.0 without losing the migration capability.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 5, 2020 at 12:45 PM Mark Mielke <<a href="mailto:mark.mielke@gmail.com">mark.mielke@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all:<div><br></div><div>With 6.4.0, live migration was working fine with Qemu 5.0. After trying out 6.5.0, migration broke with the following error:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:monospace">libvirt.libvirtError: internal error: unable to execute QEMU command 'migrate': State blocked by non-migr</span><span style="font-family:monospace">atable CPU device (invtsc flag)</span></div></blockquote><div><br></div><div>I believe I traced the error back to this commit:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="monospace">commit 201bd5db639c063862b0c1b1abfab9a9a7c92591</font></div><div><font face="monospace">Author: Jiri Denemark <<a href="mailto:jdenemar@redhat.com" target="_blank">jdenemar@redhat.com</a>></font></div><div><font face="monospace">Date:   Tue Jun 2 15:34:07 2020 +0200</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">    qemu: Fill default value in //cpu/@migratable attribute</font></div><div><font face="monospace">    </font></div><div><font face="monospace">    Before QEMU introduced migratable CPU property, "-cpu host" included all</font></div><div><font face="monospace">    features that could be enabled on the host, even those which would block</font></div><div><font face="monospace">    migration. In other words, the default was equivalent to migratable=off.</font></div><div><font face="monospace">    When the migratable property was introduced, the default changed to</font></div><div><font face="monospace">    migratable=on. Let's record the default in domain XML.</font></div><div><font face="monospace">    </font></div><div><font face="monospace">    Signed-off-by: Jiri Denemark <<a href="mailto:jdenemar@redhat.com" target="_blank">jdenemar@redhat.com</a>></font></div><div><font face="monospace">    Reviewed-by: Michal Privoznik <<a href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a>></font></div></blockquote><div><br></div><div>Before this change, qemu was still being launched with "-cpu host", which for any somewhat modern version of qemu, defaults to migratable=on. The above comment acknowledges this, however, the implementation chooses the pessimistic and ancient (and no longer applicable!) value of migratable=off:</div><div><br></div><div><font face="monospace">+    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><b>+        else if (ARCH_IS_X86(def->os.arch))<br>+            def->cpu->migratable = <font color="#cc0000">VIR_TRISTATE_SWITCH_OFF</font>;</b><br>+    }<br></font><div><br></div><div>Consequently, after live migration qemu is started with "-cpu host,migratable=off" and this enables invtsc, which then prevents migration as when invtsc is enabled it activates a migration blocker.</div><div><br></div><div>I think this patch should be reverted. If the migratable state cannot be determined, then it should not be guessed. It should be left as "absent", just as it has been working fine prior to libvirt-6.5.0. Qemu still knows what flags are enabled, so Qemu remains the authority on what can be safely migrated, and what cannot be. I reverted this patch and re-built, and this seems to clear the migration problems. If the user chooses to explicitly specify migratable=yes or migratable=no, then this value should be preserved and passed through to the Qemu "-cpu host,XXX" option.</div><div><br></div><div>I think it is not a requirement for "migratable=XXX" to be explicit in libvirt. However, if there is some reason I am unaware of, and it is important for libvirt to know, then I think it is important for libvirt to find out the authoritative state rather than guessing.</div><div><br></div><div>Please start by reverting this patch, so that other people do not get broken in the same way, and I don't need to carry my revert patch. Personally, I think this is important enough to build a 6.5.1. However, since I have a local revert patch in place, I am not waiting for this.</div><div><br></div><div>Thanks!</div><div><br></div>-- <br><div>Mark Mielke <<a href="mailto:mark.mielke@gmail.com" target="_blank">mark.mielke@gmail.com</a>><br><br></div></div></div>
</blockquote></div><br clear="all"><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>