Re: [Qemu-devel] [RFC 1/1] Execute arbitrary QMP commands from command line

[Daniel P. Berrange]

On Thu, Jan 29, 2015 at 03:46:35PM +0000, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (address@hidden) wrote:
> > On Thu, Jan 29, 2015 at 03:22:55PM +0000, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (address@hidden) wrote:
> > > > On Thu, Jan 29, 2015 at 03:06:37PM +0000, Dr. David Alan Gilbert (git) 
> > > > wrote:
> > > > > From: "Dr. David Alan Gilbert" <address@hidden>
> > > > > 
> > > > > 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.
> 
> Hmm I'm not sure; I've had a dig and the tests for INMIGRATE do a lot of 
> random
> things; qxl, usb, and blockdev for starters, and the block stuff sets a flag
> that is then passed to qcow and other backends that do stuff all over with it.
> 
> Howver, something like:
> 
>    -incoming pause
> 
> followed by the monitor command later should work - how do you feel
> about that?

That's workable from the libvirt POV. We'll probe the existance of the
'migrate-incoming' QMP command when getting capabilities, so we'll know
upfront that we can use the "-incoming pause" approach.

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 :|