From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ36S-0006Gs-PJ for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:19:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ36M-0006E9-BP for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:19:46 -0400 Received: from [199.232.76.173] (port=43385 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ36M-0006Dy-1V for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:19:42 -0400 Received: from mx1.redhat.com ([66.187.233.31]:33584) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ36L-0007ci-KK for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:19:41 -0400 Date: Tue, 23 Jun 2009 11:19:39 +0100 From: "Daniel P. Berrange" Message-ID: <20090623101939.GG6881@redhat.com> References: <20090623013005.39e27923@doriath> <4A409A4D.8030605@siemens.com> <20090623100428.GD6881@redhat.com> <4A40AA3D.2050807@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A40AA3D.2050807@siemens.com> Subject: [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: aliguori@us.ibm.com, ehabkost@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , avi@redhat.com 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, > >>> > >>> Where 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 > >> 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 :|