migration: stable machine types?

migration: stable machine types?

[Michael Tokarev]

Hi!

We had a few examples when a bugfix required for a stable series
but it can't be applied because it breaks migration.  One recent
example is https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2131822 -
the fix has been cherry-picked for 10.0.x but had to be reverted.

I wonder if we can, sometimes, introduce additional machine types
for stable series.

In this case, it might've been an intermediate 10.0.4 machine type,
which is between 10.0 and 10.1 - with this additional change included.

If this machine is known to both 10.1-tobe and 10.0.4+, all migration
should work fine in both directions.

It is exactly the same situation and solution which has been implemented
by ubuntu in the end, but using their own, distribution-specific,
machine types.

Why can't we do the same in upstream qemu?

And yes, that would be a very rare case.

Thanks,

/mjt

Re: migration: stable machine types?

[Daniel P. Berrangé]

On Sat, Feb 21, 2026 at 09:55:55AM +0300, Michael Tokarev wrote:
> Hi!
> 
> We had a few examples when a bugfix required for a stable series
> but it can't be applied because it breaks migration.  One recent
> example is https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2131822 -
> the fix has been cherry-picked for 10.0.x but had to be reverted.
> 
> I wonder if we can, sometimes, introduce additional machine types
> for stable series.
> 
> In this case, it might've been an intermediate 10.0.4 machine type,
> which is between 10.0 and 10.1 - with this additional change included.
> 
> If this machine is known to both 10.1-tobe and 10.0.4+, all migration
> should work fine in both directions.

Yep, any bug fix machine would need to be added to 'master' branch
too, and any intermediate stable branches - though the latter probably
wouldn't ever happen as machine version mistakes are usually discovered
reasonably soon.

> It is exactly the same situation and solution which has been implemented
> by ubuntu in the end, but using their own, distribution-specific,
> machine types.
> 
> Why can't we do the same in upstream qemu?

There is no constraint from a technical POV. The macros I introduced
for defining versioned machine types in a standardized manner, can
have variants provided that define "bug fix" machines for stable
branches. We have a pretty old example for Q35:

  hw/i386/pc_q35.c:DEFINE_Q35_MACHINE_BUGFIX(4, 0, 1);

We used to have another example for PPC, which used the _MACHINE_TAGGED
variant, which added a string suffix instead of a micro version number,
but I'd recommend we don't use string suffixes again, only micro versions.

The core reason we didn't do this in the past was the support workload,
as every extra machine type we add is one more thing to maintain...
previously this burden was forever, but at least now we have capped
versioned machines at 6 years / 18 minor releases total lifetime.
Thus if we did add bugfix machines, that burden is now capped and
thus more tolerable.


IOW, if you as stable maintainer want to add a bugfix machine, and
the subsystem maintainer for that machine is aggreeable to adding
it too, there is no fundamental blocker here.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: migration: stable machine types?

[Peter Xu]

On Mon, Feb 23, 2026 at 10:46:49AM +0000, Daniel P. Berrangé wrote:
> On Sat, Feb 21, 2026 at 09:55:55AM +0300, Michael Tokarev wrote:
> > Hi!
> > 
> > We had a few examples when a bugfix required for a stable series
> > but it can't be applied because it breaks migration.  One recent
> > example is https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2131822 -
> > the fix has been cherry-picked for 10.0.x but had to be reverted.
> > 
> > I wonder if we can, sometimes, introduce additional machine types
> > for stable series.
> > 
> > In this case, it might've been an intermediate 10.0.4 machine type,
> > which is between 10.0 and 10.1 - with this additional change included.
> > 
> > If this machine is known to both 10.1-tobe and 10.0.4+, all migration
> > should work fine in both directions.
> 
> Yep, any bug fix machine would need to be added to 'master' branch
> too, and any intermediate stable branches - though the latter probably
> wouldn't ever happen as machine version mistakes are usually discovered
> reasonably soon.
> 
> > It is exactly the same situation and solution which has been implemented
> > by ubuntu in the end, but using their own, distribution-specific,
> > machine types.
> > 
> > Why can't we do the same in upstream qemu?
> 
> There is no constraint from a technical POV. The macros I introduced
> for defining versioned machine types in a standardized manner, can
> have variants provided that define "bug fix" machines for stable
> branches. We have a pretty old example for Q35:
> 
>   hw/i386/pc_q35.c:DEFINE_Q35_MACHINE_BUGFIX(4, 0, 1);
> 
> We used to have another example for PPC, which used the _MACHINE_TAGGED
> variant, which added a string suffix instead of a micro version number,
> but I'd recommend we don't use string suffixes again, only micro versions.
> 
> The core reason we didn't do this in the past was the support workload,
> as every extra machine type we add is one more thing to maintain...
> previously this burden was forever, but at least now we have capped
> versioned machines at 6 years / 18 minor releases total lifetime.
> Thus if we did add bugfix machines, that burden is now capped and
> thus more tolerable.
> 
> 
> IOW, if you as stable maintainer want to add a bugfix machine, and
> the subsystem maintainer for that machine is aggreeable to adding
> it too, there is no fundamental blocker here.

Then does it mean we may sometimes need to add >1 new bugfix machine types
for one fix?

Consider if somethinig was broken in QEMU 10.0 release, then in 11.0 QEMU
we fixed it and marked backport (which will break guest ABI).

If we want to backport that change to older systems (that is, in this case
10.0, 10.1, 10.2), IIUC we need to introduce three machines (for example,
10.0.3, 10.1.2, 10.2.1), rather than one bugfix machine type.  IIUC we'll
need all these machine types available in master branch and intermediate
stable branches?

I also don't see if there's any technical issues to solve, it's just that
it looks like we can still grow quite some bugfix machine types all over
different branches.

Thanks,

-- 
Peter Xu

Re: migration: stable machine types?

[Daniel P. Berrangé]

On Mon, Feb 23, 2026 at 02:37:16PM -0500, Peter Xu wrote:
> On Mon, Feb 23, 2026 at 10:46:49AM +0000, Daniel P. Berrangé wrote:
> > On Sat, Feb 21, 2026 at 09:55:55AM +0300, Michael Tokarev wrote:
> > > Hi!
> > > 
> > > We had a few examples when a bugfix required for a stable series
> > > but it can't be applied because it breaks migration.  One recent
> > > example is https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2131822 -
> > > the fix has been cherry-picked for 10.0.x but had to be reverted.
> > > 
> > > I wonder if we can, sometimes, introduce additional machine types
> > > for stable series.
> > > 
> > > In this case, it might've been an intermediate 10.0.4 machine type,
> > > which is between 10.0 and 10.1 - with this additional change included.
> > > 
> > > If this machine is known to both 10.1-tobe and 10.0.4+, all migration
> > > should work fine in both directions.
> > 
> > Yep, any bug fix machine would need to be added to 'master' branch
> > too, and any intermediate stable branches - though the latter probably
> > wouldn't ever happen as machine version mistakes are usually discovered
> > reasonably soon.
> > 
> > > It is exactly the same situation and solution which has been implemented
> > > by ubuntu in the end, but using their own, distribution-specific,
> > > machine types.
> > > 
> > > Why can't we do the same in upstream qemu?
> > 
> > There is no constraint from a technical POV. The macros I introduced
> > for defining versioned machine types in a standardized manner, can
> > have variants provided that define "bug fix" machines for stable
> > branches. We have a pretty old example for Q35:
> > 
> >   hw/i386/pc_q35.c:DEFINE_Q35_MACHINE_BUGFIX(4, 0, 1);
> > 
> > We used to have another example for PPC, which used the _MACHINE_TAGGED
> > variant, which added a string suffix instead of a micro version number,
> > but I'd recommend we don't use string suffixes again, only micro versions.
> > 
> > The core reason we didn't do this in the past was the support workload,
> > as every extra machine type we add is one more thing to maintain...
> > previously this burden was forever, but at least now we have capped
> > versioned machines at 6 years / 18 minor releases total lifetime.
> > Thus if we did add bugfix machines, that burden is now capped and
> > thus more tolerable.
> > 
> > 
> > IOW, if you as stable maintainer want to add a bugfix machine, and
> > the subsystem maintainer for that machine is aggreeable to adding
> > it too, there is no fundamental blocker here.
> 
> Then does it mean we may sometimes need to add >1 new bugfix machine types
> for one fix?
> 
> Consider if somethinig was broken in QEMU 10.0 release, then in 11.0 QEMU
> we fixed it and marked backport (which will break guest ABI).
> 
> If we want to backport that change to older systems (that is, in this case
> 10.0, 10.1, 10.2), IIUC we need to introduce three machines (for example,
> 10.0.3, 10.1.2, 10.2.1), rather than one bugfix machine type.  IIUC we'll
> need all these machine types available in master branch and intermediate
> stable branches?

If we cause a regression in an existing machine type via a backport,
we should just fix that regression, not introduce a new machine type.


A new machine type in stable should only be considered where we need
to backport a bugfix, and that fix was inherantly tied to a machine
type that exists in master, but not in stable.

Even if it is possible to do it, we should still consider each case
to decide it is it desirable to do it, given the support burden.

IOW, if we ended up with multiple bugfix machine types per stable
stream, IMHO that would be a sign we were not being anywhere near
strict enough.

I was thinking this should be something where we have 0 or 1 bug
fix machines introduced per year. ie most stable branches should
not need bugfix machine types. Only the most significant of bugs
should justify it.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|