On Tue, May 12, 2020 at 04:52:46PM +0200, Michal Privoznik wrote:
> In v4.1.0-rc0~9^2~25 QEMU deprecated -numa mem= in favor of -numa
> memdev= + -object memory-backend-*. However, the problem is these
> two are incompatible. A domain started with older cmd line can't
> be migrated to the newer one and vice versa. That is why libvirt
> hasn't switched to the new cmd line, until now.
>
> Starting with this commit, the new cmd line is used and this fact
> is then recorded in domain private data object under
> priv->forceNewNuma. This means, that the status XML and migration
> cookie have it too and thus can instruct the other daemon which
> cmd line to generate.
>
> Unfortunately, migration from newer to older style will fail.
> I'm saving the explicit check for a separate commit.
AFAICT, this isn't the approach we had discussed previously with
QEMU.
QEMU introduced a flag on the machine type "numa-mem-supported".
If libvirt sees "numa-mem-supported=false", then we must use
the new syntax, otherwise we must keep using the old syntax
for migration compatibility.
Essentially this lets us implement
if machine type version > XXX
new syntax
else
old syntax
without having to actually put a version number check into
libvirt.
QEMU has not actually set numa-mem-supported=false on any
machine types upstream yet, becuase they're waiting for libvirt
to get this wired up.
The intent is that we can get some releases of libvirt into the
wild which support numa-mem-supported=false. Then when QEMU
flips the switch in new machine types we'll just "do the right
thing".
It will only break for people who use an old libvirt with a new
QEMU which should be relatively uncommon.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
