On Tue, Apr 03, 2018 at 03:49:07PM +0200, Igor Mammedov wrote: > On Thu, 29 Mar 2018 13:57:54 -0300 > Eduardo Habkost <ehabk...@redhat.com> wrote: > > [...] > > > As for the future, I agree it would be much more flexible > > > to allow both -preconfig and -incoming at the same time, > > > so we could start target with empty CLI, and then feed it > > > options from source. It would require audit/refactoring of > > > INMIGRATE state and making 'all' current CLI options > > > available via QMP interface. > > > > > > But for now I'd prefer to keep using old way to start target. > > > > Well, if management software developers tell us that -preconfig > > will be already useful without -incoming support, I won't object. > As Peter said, mgmt can/will use -preconfig even without -incoming, > since it lets deal with initial (source) start-up problem (i.e. > avoid restarting QEMU) and lets us make numa configuration work > in qemu/libvirt stack without guess work. (that's the end goal of > the series) > > > But it would be very nice for management software if they can > > simply assume that -preconfig and -incoming will work together > > since the first version. Can we have this as a goal for 2.13? > I can't promise to refactor -incoming in near future, as I'm working > on ARM cpu-hotplug currently and next in queue is ARM memory hotplug. > > Peter suggested an alternative idea, to abandon -incoming and > enable incoming migration from QMP after all configuration is done. > Amount of refactoring need probably would be the same but at least > interface and runstate transitions wise it looks cleaner.
Also, support for the "start incoming migration" QMP command would be very easy to probe using existing mechanisms. Sounds good to me. -- Eduardo
