On Mon, 2018-02-12 at 13:20 +0100, Andrea Bolognani wrote: > On Mon, 2018-02-12 at 13:02 +1100, Alexey Kardashevskiy wrote: > > On 12/02/18 09:55, Benjamin Herrenschmidt wrote: > > > Well, we have a problem then. It looks like Qemu broken migration is > > > fundamentally incompatible with PAPR and CAS design... > > > > > > I know we don't migrate the configuration, that's not exactly what I > > > had in mind tho... Can we have some piece of *data* from the machine be > > > migrated first, and use it on the target to reconfigure the interrupt > > > controller before the stream arrives ? > > > > These days this is done via libvirt - it reads properties it needs via QMP, > > then sends an XML with everything (the interrupt controller type may be one > > of such properties), and starts the destination QEMU with the explicit > > interrupt controller (like -machine pseries,intrc=xive). > > Clarification: libvirt will use the user-defined XML configuration > to generate the QEMU command line both for the source and the target > of the migration, but it will not automagically figure out properties > through QMP. So if you want the controller to explicitly show up on > the QEMU command line, libvirt should be taught about it.
Which can't work because the guest pretty much decides what it will be early on during the boot process. So we're back to square 1 having to instanciate both objects in qemu with some kind of "activation" flag. Cheers, Ben.
