On Thu, Aug 01, 2024 at 01:51:00AM -0400, Michael S. Tsirkin wrote: > On Wed, Jul 31, 2024 at 08:57:52AM -0400, Peter Xu wrote: > > Could you elaborate why it would fail if with what I proposed? > > First I think I was wrong I misunderstood what you said. > To summarise, you said: > > - any new feature depending on another package is off by default > - starting qemu on destination with feature enabled will fail > thus migration is not started > > > My comment is that this "started" is from qemu point of view, > from user's POV starting qemu on destination is just the 1st > step of migration. > > > However I agree, this is better since we do not waste bandwidth, > and I was wrong to say we do. > > My other comment is that adding features becomes even more work > than it is now. > > So I suggest a single command that dumps some description of host > features, to be passed to qemu on destination. qemu then fails to > start on destination if some of these do not work. > The advantage is that this also helps things like -cpu host, > and a bunch of other things like vdpa where we like to pass through > config from kernel. > > The disadvantage is that it does not exactly *fix* migration, > it just does not let you start it. This feels like only half a solution, and not the most helpful half. It prevents you accidentally migrating to a host that lacks some features, but doesn't help with starting a VM that has migrate compatible features in the first place.
