From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J27LT-00030r-3W for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:48:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J27LR-0002wS-68 for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:48:30 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J27LQ-0002vP-Nv for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:48:28 -0500 Received: from el-out-1112.google.com ([209.85.162.183]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J27LO-0000mz-Oa for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:48:28 -0500 Received: by el-out-1112.google.com with SMTP id y26so414659ele for ; Tue, 11 Dec 2007 07:48:24 -0800 (PST) Message-ID: <475EB146.9000105@codemonkey.ws> Date: Tue, 11 Dec 2007 09:48:22 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API References: <475E5403.2000705@bellard.org> <1197364997.4242.10.camel@frecb07144> <475E617D.6090702@qumranet.com> <475EA3F4.50802@codemonkey.ws> <20071211150228.GD17368@redhat.com> <475EA9AA.3020503@codemonkey.ws> <475EAF65.5050809@redhat.com> In-Reply-To: <475EAF65.5050809@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Richard W.M. Jones wrote: > Anthony Liguori wrote: >> Daniel P. Berrange wrote: >>> Or have 2 monitor interaction modes. One mode uses the command line >>> style >>> suitable for people / scripting languages. The other umode ses a >>> binary XDR >>> protocol for serializing the args & returns values for formal control >>> APIs to use in a easy manner. It ought to be reasonably >>> straightforward to >>> add a binary serialization format for all existing commands >>> >> >> I don't think binary is inherently easier to parse than text provided >> that some thought is put into the format of the textual output. > > XDR (aka RFC 1014 & RFC 4506) does let you generate complex interfaces > with relative ease. For example, here's the description of the remote > protocol used by libvirt: > > http://git.et.redhat.com/?p=libvirt.git;a=blob;f=qemud/remote_protocol.x;h=d409c74387c2642651896136aba9bc1e2b62b621;hb=HEAD > > > "Parsing" is done for you by stubs that are generated from the above > file. > > On the downside it turns out that it's not very well supported under > Windows. For libvirt I had to basically port an XDR implementation by > hand to MinGW and add extra functions from glibc to it. > >> I think we just want to levels of verbosity. > > This would work too. > > On the point of controlling multiple qemu instances on a machine from > a single place: Easiest way to do this would be to direct all the > monitor sockets into a single known directory. Something along the > lines of: > > qemu -monitor unix:/var/lib/qemu-monitors/`uuidgen`,nowait > > A control process can then just keep an eye on entries under that > directory, and (unlike libvirtd) it's robust against the control > process restarting. Actually, this was the original intention of the -name parameter. What a management tool would want to do is: 1) if -name is specified by user, generate one with uuidgen 2) pass -name and -pidfile /path/to/well/known/location/name.pid This will ensure uniqueness of name without requiring the creation tool to maintain any state (so no daemon is required). Right now, you would also have to store a monitor socket in that well known path. However, I'm working on a VNC tunnels patch right now that would allow the monitor to be tunneled through a VNC session. The idea here is that a management tool could just store a hint about the VNC location and then you can get at the rest of the character devices through the VNC session. Otherwise, you end up with a bunch of temporary sockets for things like the monitor, serial devices, parallel devices, etc. Regards, Anthony Liguori > Rich. >