Re: [RFC PATCH] virtio-net: introduce strict peer feature check

[Jinpu Wang <jinpu.wang@ionos.com>]

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 <thuth@redhat.com> 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
>