[Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode

[Jan Kiszka]

Daniel P. Berrange wrote:
> On Tue, Jun 23, 2009 at 12:11:09PM +0200, Jan Kiszka wrote:
>> Daniel P. Berrange wrote:
>>> On Tue, Jun 23, 2009 at 11:03:09AM +0200, Jan Kiszka wrote:
>>>> Luiz Capitulino wrote:
>>>>> This change adds a flag called 'control' to the already existing
>>>>> '-monitor' command-line option. This flag can be used to enable
>>>>> control mode.
>>>>>
>>>>> Its syntax is:
>>>>>
>>>>> qemu [...] -monitor control,<device>
>>>>>
>>>>> Where <device> is a chardev (excluding 'vc', for obvious reasons).
>>>>>
>>>>> For example:
>>>>>
>>>>> $ qemu [...] -monitor control,tcp:localhost:4444,server
>>>>>
>>>>> Will run QEMU in control mode, waiting for a client TCP connection
>>>>> on localhost port 4444.
>>>>>
>>>>> Signed-off-by: Luiz Capitulino <address@hidden>
>>>> At this chance, I would vote for "[PATCH 12/11] Allow multiple -monitor
>>>> instances". I think Anthony posted such a patch before. Now we should
>>>> really include this as your extension may block the stand-alone -monitor
>>>> switch for the control channel, preventing to additionally set up one
>>>> (or more) for debugging purposes.
>>> If we support multiple monitors, it might be desirable to allow the
>>> app owning the main 'control' monitor channel to be able to indicate
>>> that additional monitor channels are read-only. eg, so libvirt could
>>> allow the user to connect to the monitor to run 'info' commands for
>>> debug support without risk of having state changed behind its back
>> Couldn't libvirt deal with update given we provide them as events?
>> Otherwise, your suggestion makes sense, definitely as long as it would
>> wreck libvirt's internal house keeping or for commands that are not
>> synchronizable.
> 
> If the mgmt app knows about & supports all features in the QEMU its 
> talking to, and we generate events for all possible changes, then it
> could detect & cope with changes. In reality though I don't think
> you can expect mgmt apps to have complete coverage of all features,
> so it would be safer for them to be able to designate additional 
> monitor channels readonly.

Also reading your valid concerns regarding event queue overflows, I
think making it flexible /wrt asynchronous changes will actually make
the whole think much more robust than simply trying to block every
competing change.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux