On Thu, Jan 29, 2015 at 03:22:55PM +0000, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Thu, Jan 29, 2015 at 03:06:37PM +0000, Dr. David Alan Gilbert (git)
> > wrote:
> > > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
> > >
> > > For an incoming migration it's potentially useful to be able to set
> > > capabilities and parameters prior to opening the connection, while
> > > a separate option for that would have been possible it seems better
> > > to give access to all the existing migration capabilities, parameters
> > > etc. The least restrictive way of doing this is to allow arbitrary
> > > QMP commands to be executed prior to the -incoming being processed.
> > >
> > > As an example:
> > >
> > > ./bin/qemu-system-x86_64 -nographic -nodefaults -qmp-command '{"execute":
> > > "migrate-set-capabilities",
> > > "arguments":{"capabilities":[{"capability":"xbzrle","state":true}]}}'
> > > -qmp-command '{"execute": "query-migrate-capabilities"}' -incoming
> > > tcp::444
> >
> > I'm unclear how we'd easily deal with the response from commands
> > invoked this way, to get replies and/or errors. Also, it might
> > be the case that we need to conditionally run certain commands
> > depending on the result of earlier commands.
> >
> > Wouldn't it make more sense to simply add a 'migrate_incoming' QMP
> > command, and stop using -incoming altogether, so we just have normal
> > QMP access ?
> >
> > eg,
> >
> > # qemu-system-x86_64 ....device args... -S
> > (qmp) ....arbitrary QMP commands ..
> > (qmp) {"execute":"migrate-incoming", "arguments": { "uri": "tcp::44" }}
>
> I'm a bit worried about whether starting an incoming migrate afterwards is
> different in any subtle way. I can see there are a handful of devices that
> have 'runstate_check(RUN_STATE_INMIGRATE)' calls in, and thus I'm not sure
> that starting a paused VM and then flipping to RUN_STATE_INMIGRATE would
> be quite the same.
>
> Having said that, we do have 'loadvm' that's similar to an incoming migration.
Yep, existance of 'loadvm' does give confidence that this should work with
migration, hopefully only needing a few cleanups for the state check you
mention above.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
