On Fri, Jul 26, 2024 at 03:25:31AM -0400, 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@daynix.com> Signed-off-by: Andrew Melnychecnko <andrew@daynix.com>
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.
The question is how should an user know a migration is not supported? The user can be using exactly the same QEMU binary on two hosts, while there can be a tiny slight difference in host kernel version, then migration can fail between them misterously. There're too many kernel features that can be on/off when kernels are different, even if slightly. Then I don't see how someone can even identify such issue, unless one uses exactly the same host kernels on both sides.. -- Peter Xu