Re: [PATCH] ui/vdagent: add migration blocker when machine version < 10.1

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Jan 13, 2026 at 12:20:12PM +0100, Fiona Ebner 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 <f.ebner@proxmox.com
> > <mailto:f.ebner@proxmox.com>> 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?

I guess it gets fuzzy because the general concept of machine types
is

  "what previously worked must still work in future, given an
   identical machine config".

Marc-andre's patch took something which was previously broken, and
made it work, for both new and pre-existing machine types, but only
if both sides used the new QEMU binary. This is somewhat unusual,
but probably not without precedent wrt other places where we have
removed historical blockers.

In this case, the patch is proposing to extend the above concept to
include "what was previously broken must remain broken", wrt pre-
existing machine types.

I have some sympathy for the latter proposal, because the way that
failures loading vmstate present themselves is very user hostile.

At least with migration you'll see the error after migration
completes, which is still "in the moment". If you're using a
save/restore workflow, as you might only discover this config
is not restorable on your desired older QEMU weeks or months
later.

IOW using an old machine type and the user config sometimes be
migratable and sometimes not migratable is poor user experiance
IMHO.


> 
> >  
> > 
> >     > 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: qemu-stable@nongnu.org <mailto:qemu-stable@nongnu.org>
> >     Fixes: 42000e0013 ("ui/vdagent: remove migration blocker")
> >     Signed-off-by: Fiona Ebner <f.ebner@proxmox.com
> >     <mailto:f.ebner@proxmox.com>>
> >     ---
> >      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
> 
> 

With 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 :|