Thanks for identifying that change hector, there probably is another for pdcm somewhere. But we can not revert that forever, after all it fixes other real issues.
Historically such changes that make a difference if you say -model pc-i440fx-10.0 -cpu foo,feature1=on,feature2=off to mean something different in the new version of qemu have been hidden behind compat handling in the cpu types and such. Example: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/core/machine.c#L43 Which is used in machine definitions: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/i386/pc_piix.c#L453 So it used to be ok that -cpu foo,feature1=on,feature2=off is different to -cpu foo,feature1=on,feature2=off in new version Or -model pc-i440fx-10.0 -cpu foo,feature1=on,feature2=off is different than -model pc-i440fx-10.1 -cpu foo,feature1=on,feature2=off due to the new version But -model pc-i440fx-10.0 -cpu foo,feature1=on,feature2=off used to stay the same to -model pc-i440fx-10.0 -cpu foo,feature1=on,feature2=off in a newer version. Essentially following it as outlined in https://gitlab.com/qemu- project/qemu/-/blob/master/docs/devel/migration/compatibility.rst It has the correct statement "We broke migration for old machine types continuously during development. But as soon as we find that there is a problem, we fix it. The problem is what happens when we detect after we have done a release that something has gone wrong." which we face as well. But if we could agree with upstream on something for the upcoming 11.0 and we could add it to questing before questing is out we could still save Ubuntu and future qemu releases. Either in qemu compat handling or in libvirt detecting and constructing the guest with different arguments (as outlined in the doc) IMHO we need to raise this upstream outlining what and why we see. While they are not as concerned about cross version migration, they are not at all actively against it. And they might just not be aware, or aware and much further than we are. We need to ask what they think in general and if they would be open think of adding such compat as in the past. If so maybe to a future version. And if the inbetween would be expected to be handled by libvirt via different commandline args (also as outlined in the doc). For the proper report I think you need to collect the full commandline that old and new stack generates on source and destination - usually best grabbed from /var/log/libvirt/qmeu/guestname.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2121787 Title: Cross release migration broken to questing (q 10.1/ lv 11.6) - "missing features: pdcm,arch-capabilities" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2121787/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
