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.
--
MST