On Wed, Jul 31, 2024 at 08:57:52AM -0400, Peter Xu wrote: > > > > The right solution is to have a tool that can query > > backends, and that given the results from all of the cluster, > > generate a set of parameters that will ensure migration works. > > Kind of like qemu-img, but for migration. > > This is adding extra work, IMHO. Agreed that it's a lot of work. > If we stick with "qemu cmdline as guest ABI" concept, I think we're all > fine, as that work is done by QEMU booting up first on both sides, > including dest. Basically Libvirt already plays this role of the new tool > without any new code to be added at all: what captured on the boot failure > log will be the output of that tool if we write it. However, this means we can never add new features without also teaching libvirt to enable them. How about we add some kind of command on source qemu to return description of all working features? Then when qemu is started on destination, this data can be passed in, and validated. Hmm? -- MST
