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(a)daynix.com>
> > > > Signed-off-by: Andrew Melnychecnko <andrew(a)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