qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P. Berrange
Subject: [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode
Date: Tue, 23 Jun 2009 11:19:39 +0100
User-agent: Mutt/1.4.1i

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.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]