* Eric Blake (ebl...@redhat.com) wrote: > 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.
Compared to just taking a URI argument that Dan suggested, that's quite a bit of rework to do the reworking of each transport which is pretty trivial. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK