qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 3/9] cli: add -preconfig option


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v4 3/9] cli: add -preconfig option
Date: Mon, 30 Apr 2018 20:12:09 +0100
User-agent: Mutt/1.9.5 (2018-04-13)

* Eduardo Habkost (address@hidden) wrote:
> On Tue, Apr 03, 2018 at 03:49:07PM +0200, Igor Mammedov wrote:
> > On Thu, 29 Mar 2018 13:57:54 -0300
> > Eduardo Habkost <address@hidden> 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.

You could stick to -incoming defer,   that already says that you want
to do an inward migration but doesn't say where from until later.

Note there are some other bits of code scattered around for
checking whether we're in -incoming mode, for example to stop you
do an outwards migration while waiting for an incoming one, or
to stop you doing a migrate-incoming while you're already waiting
for one.

Dave

> -- 
> Eduardo
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]