Hello all, My apologies for the slow reply; I have been heavily involved in other tasks recently.
I wanted to chime in to confirm that, as a Cloud Service Provider (CSP), we rely heavily on live migration, particularly during the rollout of new host operating system versions or for resource balancing across our infrastructure. Consequently, it is a critical requirement for us that the live migration process remains robust and does not experience failures simply because new features are automatically enabled by default when running on a newer kernel version. >From the CSP perspective, having a strict feature check that results in a failure at boot (or feature negotiation) seems significantly preferable to the previous behavior of silently clearing features and only failing much later during a migration attempt. A strict check provides immediate feedback that the requested feature set is incompatible with the peer/environment, allowing us to address the configuration issue proactively before the VM is put into production or before a migration is attempted. I must admit I don't know the code base well enough to comment on the technical implementation, but the principle behind the proposed strict check appears to align well with our operational needs for managing live migration compatibility and stability. Thank you very much, Jason, for proposing and working on this solution. Best regards, Jinpu On Fri, Nov 14, 2025 at 6:48 AM Thomas Huth <[email protected]> wrote: > > On 13/11/2025 20.32, Peter Xu wrote: > > On Thu, Nov 13, 2025 at 12:46:55PM -0500, Michael S. Tsirkin wrote: > >> failing to start a perfectly good qemu which used to work > >> because you changed kernels is better than failing to migrate how? > >> > > > > I agree this is not pretty. > > > > The very original proposal was having extra features to be OFF by default, > > only allow explicit selections to enable them when the mgmt / user is aware > > of the possible hosts to run on top. > > Could it maybe be tied to the "-nodefaults" option of QEMU? If you run QEMU > with "-nodefaults" (which you should do when planning a migration later), > these extra features that depend on the kernel version stay OFF. If you run > QEMU without "-nodefaults", QEMU could enable them if supported by the > kernel. So that would benefit both, the people running QEMU via management > layers (using -nodefaults), and the people who just want to quickly launch > QEMU on the command line. WDYT? > > Thomas >
