From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I38bU-0001OO-Pa for qemu-devel@nongnu.org; Tue, 26 Jun 2007 06:49:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I38bS-0001LU-N0 for qemu-devel@nongnu.org; Tue, 26 Jun 2007 06:48:59 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I38bR-0001Kj-LX for qemu-devel@nongnu.org; Tue, 26 Jun 2007 06:48:57 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I38bQ-00011v-Q0 for qemu-devel@nongnu.org; Tue, 26 Jun 2007 06:48:57 -0400 Received: by py-out-1112.google.com with SMTP id f47so135110pye for ; Tue, 26 Jun 2007 03:48:54 -0700 (PDT) Message-ID: <72e9f71c0706260348h598ffc64meca8c313cfb93326@mail.gmail.com> Date: Tue, 26 Jun 2007 12:48:54 +0200 From: "Jannes Faber" Sender: jannes.faber@gmail.com Subject: Re: [Qemu-devel] [PATCH] starting qemu vnc session on a pre-allocated port In-Reply-To: <4680E7BB.80408@codefidence.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3500_31399623.1182854934504" References: <467E6C25.3010908@codefidence.com> <467E7AB0.1000909@codemonkey.ws> <467EE5E0.5010605@codefidence.com> <467EF2D6.90501@codemonkey.ws> <467F7CC6.6000207@codefidence.com> <467FAD19.4000404@codemonkey.ws> <4680E7BB.80408@codefidence.com> 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 ------=_Part_3500_31399623.1182854934504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/26/07, Gilad Ben-Yossef wrote: > > Anthony Liguori wrote: > > > It also > > implies that the daemon will be running for the entire lifetime of the > > VM. > > No. In fact, running an extra daemon for the entire life time of the > VM is exactly what I'm trying to avoid (one of the things, anyway). > > Now I see why you think the unix domain socket option solves the problem > already. Our use case is actully a little different. Let me explain: > > The machine running qemu has a web based interface to start VMs. > A user asks for a new VM to start by browsing to a URL. The CGI > implmenting that URL will start a new qemu instance, send to the user > web browser an HTML page with a JAVA VNC viewer embedded and terminate. > > Here is the problem: the HTML page needs to have the port number > for the JAVA VNC viewer to connect to embedded in it. > > Of course, the CGI can pick a free port and ask qemu to start the VNC > server on it, but it means CGI needs to maintain a list of free/used > port ranges in some shared data structue, track the qemu instance to know > when it is termianted and the port is free again and of course, hope that > not non related proccess will snatch a port in the port range and > generally > duplicate the ifnormation the operating system already has on free/in use > ports. > > In our suggested solution, our CGI simply opens a listening socket on an > ethermal port, letting the OS do the allocation, hands the file descriptor > to qemu to use and *terminates* (after sending the HTML page). > No long running daemons. > > Having a daemon sit around just to shove the data from the Unix domain > socket > to the TCP socket and back and needing to track it and all really puts an > ugly > dent on the whole idea and, more important - I think what we are doing is > a rather general concept, certainly not unique to us (just look at qemudo, > only of course, they got it wrong... :-) > > Hope this explains things a little better. Isn't your suggestion also how xinetd works? I guess starting qemu from an xinetd could be useful as well in some use cases. A client can simply VNC to a server (on the standard port). xinetd listens on that port, starts a qemu passing it the connection handle. I guess the disadvantage would be that as soon as you loose the VNC connection you can't get it back anymore. > Gilad > > -- Jannes Faber ------=_Part_3500_31399623.1182854934504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/26/07, Gilad Ben-Yossef <gilad@codefidence.com> wrote:
Anthony Liguori wrote:

> It also
> implies that the daemon will be running for the entire lifetime of the
> VM.

No. In fact, running an extra daemon for the entire life time of the
VM is exactly what I'm trying to avoid (one of the things, anyway).

Now I see why you think the unix domain socket option solves the problem
already. Our use case is actully a little different. Let me explain:

The machine running qemu has a web based interface to start VMs.
A user asks for a new VM to start by browsing to a URL. The CGI
implmenting that URL will start a new qemu instance, send to the user
web browser an HTML page with a JAVA VNC viewer embedded and terminate.

Here is the problem: the HTML page needs to have the port number
for the JAVA VNC viewer to connect to embedded in it.

Of course, the CGI can pick a free port and ask qemu to start the VNC
server on it, but it means CGI needs to maintain a list of free/used
port ranges in some shared data structue, track the qemu instance to know
when it is termianted and the port is free again and of course, hope that
not non related proccess will snatch a port in the port range and generally
duplicate the ifnormation the operating system already has on free/in use
ports.

In our suggested solution, our CGI simply opens a listening socket on an
ethermal port, letting the OS do the allocation, hands the file descriptor
to qemu  to use and *terminates* (after sending the HTML page).
No long running daemons.

Having a daemon sit around just to shove the data from the Unix domain socket
to the TCP socket and back and needing to track it and all really puts an ugly
dent on the whole idea and, more important - I think what we are doing is
a rather general concept, certainly not unique to us (just look at qemudo,
only of course, they got it wrong... :-)

Hope this explains things a little better.

Isn't your suggestion also how xinetd works? I guess starting qemu from an xinetd could be useful as well in some use cases. A client can simply VNC to a server (on the standard port). xinetd listens on that port, starts a qemu passing it the connection handle.

I guess the disadvantage would be that as soon as you loose the VNC connection you can't get it back anymore.


Gilad


--
Jannes Faber ------=_Part_3500_31399623.1182854934504--