Eric Blake <ebl...@redhat.com> writes:
> 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.
Seconded.
>>
>> 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.
Yup.
