Hi On Tue, Jan 13, 2026 at 3:21 PM Fiona Ebner <[email protected]> wrote: > > 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?
Makes sense, I actually wrote that ramfb x-migrate and nobody complained about that behaviour: commit a1e88d2d2b89ad6371036aa07f7e96947786c873 Author: Marc-André Lureau <[email protected]> Date: Mon Oct 9 10:32:46 2023 +0400 ramfb-standalone: add migration support Add a "ramfb-dev" section whenever "x-migrate" is turned on. Turn it off by default on machines <= 8.1 for compatibility reasons. Signed-off-by: Marc-André Lureau <[email protected]> Reviewed-by: Laszlo Ersek <[email protected]> Acked-by: Gerd Hoffmann <[email protected]> Signed-off-by: Cédric Le Goater <[email protected]> So let's take the same approach for qemu-vdagent Reviewed-by: Marc-André Lureau <[email protected]> -- Marc-André Lureau
