[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC: async commands with QMP
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] RFC: async commands with QMP |
Date: |
Wed, 29 Jul 2015 09:10:54 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 |
On 07/29/2015 09:05 AM, Daniel P. Berrange wrote:
>> In order to make "async" variant possible, "id" would have to be
>> provided and unique. I think the async support should also be
>> announced in the qmp_capabilities. Commands would have to opt-in for
>> async support in the schema. An async return wouldn't be allowed when
>> a blocking command is ongoing.
>>
>> There are many variations possible on the same idea. We could
>> introduce new _async functions instead, and keep the "id"
>> requirements. Or alternatively, an "async_id" could be generated by
>> qemu and returned immediately. Then the reply of the command could be
>> an event instead. Ex:
>>
>
> When QMP was originally written there was some infrastructure for doing
> async commands, but over time this has all been ripped out because it
> was never really used, complicated the code and didn't work too well
> either. It seems we pretty much settled on the approach that all
> commands should be fast to execute, and where there is a long term
> job being run, we have commands to query its status, cancel it, and
> sometimes events too.
In fact, see commit 65207c59, where we ripped it out with prejudice.
> One of the benefits of this is that it means
> that libvirt can determine current status of ongoing background jobs
> when it restarts and reconnects to a previously launched QEMU, where
> as an async command approach is tied to the specific monitor connection
> that is open.
And that is a real concern with any new proposal for async commands.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature