Re: [Qemu-devel] [PATCH] starting qemu vnc session on a pre-allocated port

["Jannes Faber" <j.faber@elevate.nl>]

[-- Attachment #1: Type: text/plain, Size: 2406 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3197 bytes --]