On 01/29/2015 08:15 AM, Daniel P. Berrange wrote:

>> ./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 ?

I agree - shoving more into the command line is the wrong direction;
full power is better obtained by making the command line be the minimal
needed to get into QMP control, and let QMP kick things off.

> 
> eg,
> 
>     #  qemu-system-x86_64 ....device args...  -S
>     (qmp) ....arbitrary QMP commands ..
>     (qmp) {"execute":"migrate-incoming", "arguments": { "uri": "tcp::44" }}

The idea of a QMP command to trigger incoming migration looks
reasonable.  We can probably use a qapi union for a nicer syntax,
something like:

{"execute": "migrate-incoming", "arguments": {
  "type": "tcp", "port": 44 } }
vs.
{"execute": "migrate-incoming", "arguments": {
  "type": "fd", "fd": 0 } }
vs.
{"execute": "migrate-incoming", "arguments": {
  "type": "exec", "command": [ "cat", "/path/to/file" ] } }

and so forth.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org