Hi Marc-André, Am 13.01.26 um 8:39 AM schrieb Marc-André Lureau: > Hi Fiona > > On Mon, Jan 12, 2026 at 2:51 PM Fiona Ebner <[email protected] > <mailto:[email protected]>> wrote: > > In QEMU 10.1, commit 5d56bff11e ("ui/vdagent: add migration support") > added migration support for the vdagent chardev and commit 42000e0013 > ("ui/vdagent: remove migration blocker") removed the migration > blocker. No compat for older machine versions was added, so migration > with pre-10.1 machine version, from a 10.1 binary to a pre-10.1 binary > will result in a failure when loading the VM state in the target > instance: > > > But you can migrate a pre-10.1 machine with the new binary.
True, but I think it violates what a machine version is supposed to encapsulate. If a QEMU binary supports a given machine version, it should be able to load migration streams originating from other, newer QEMU binaries when the same machine version and commandline is used, or? > > > > Unknown savevm section or instance 'vdagent' 0. Make sure that your > > current VM setup matches your saved VM setup, including any > > hotplugged devices > > Add a compat flag to block migration when the machine version is less > than 10.1 to avoid this. > > > I am not sure this is the right way to handle this. There is already > this error when migrating to an older qemu, I am not sure we have to > block earlier and prevent the above case. I would consider this an internal/unexpected error. I feel like it should not occur if the VM was started with the exact same commandline on source and target, but currently, it can. It happens at the very end of migration when the source is already in post-migrate state, which is not nice for users/management layer. > > > > Cc: [email protected] <mailto:[email protected]> > Fixes: 42000e0013 ("ui/vdagent: remove migration blocker") > Signed-off-by: Fiona Ebner <[email protected] > <mailto:[email protected]>> > --- > hw/core/machine.c | 1 + > ui/vdagent.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 47 insertions(+) > > diff --git a/hw/core/machine.c b/hw/core/machine.c > index 6411e68856..9a5241ce17 100644 > --- a/hw/core/machine.c > +++ b/hw/core/machine.c > @@ -55,6 +55,7 @@ GlobalProperty hw_compat_10_0[] = { > { "vfio-pci", "x-migration-load-config-after-iter", "off" }, > { "ramfb", "use-legacy-x86-rom", "true"}, > { "vfio-pci-nohotplug", "use-legacy-x86-rom", "true" }, > + { "chardev-qemu-vdagent", "x-migration-blocked", "true" }, > > > Is there a precedent where such compat property was added to block > migration? There are several ones where migration is turned off for a device or certain properties, e.g. { "ramfb", "x-migrate", "off" } for 8.1 { "pl011", "migrate-clk", "off" } for 5.1 which is not quite the same, but I'd still argue: I guess those properties were not migrated, so compatibility means still not migrating those for older machine version. For the vdagent chardev, the previous behavior was blocking migration, so compatibility means still blocking migration for older machine versions. Or does that not make sense? Best Regards, Fiona
