On 26/07/2024 09.25, Michael S. Tsirkin wrote:
On Fri, Jul 26, 2024 at 09:03:24AM +0200, Thomas Huth wrote:
On 26/07/2024 08.08, Michael S. Tsirkin wrote:
On Thu, Jul 25, 2024 at 06:18:20PM -0400, Peter Xu wrote:
On Tue, Aug 01, 2023 at 01:31:48AM +0300, Yuri Benditovich wrote:
USO features of virtio-net device depend on kernel ability
to support them, for backward compatibility by default the
features are disabled on 8.0 and earlier.
Signed-off-by: Yuri Benditovich <yuri.benditovich@xxxxxxxxxx>
Signed-off-by: Andrew Melnychecnko <andrew@xxxxxxxxxx>
Looks like this patch broke migration when the VM starts on a host that has
USO supported, to another host that doesn't..
This was always the case with all offloads. The answer at the moment is,
don't do this.
May I ask for my understanding:
"don't do this" = don't automatically enable/disable virtio features in QEMU
depending on host kernel features, or "don't do this" = don't try to migrate
between machines that have different host kernel features?
The later.
From my experience, it should rather be the former. We've seen similar
issues with the s390x machine in the past when trying to automatically
enable features depending on the availability of a kernel features. While it
looks nicer at a very first glance ("hey, a new feature is available, we
enable that for you, dear user!"), you end up in migration hell pretty quickly.
Maybe we could elevate the "--nodefaults" command line switch to avoid
enabling such features automatically?
Anyway, while we're discussing solutions: We are in softfreeze already.
Should we disable the UFO bits in the new 9.1 machine type for the time
being to avoid that more people are running into this problem?
Thomas
