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.
Since VM's are meant to run for very long periods of time, this is
quite limiting. By utilizing a domain socket, you gain the ability
to record on disk the state of the daemon and then restart. The
layer of redirection also allows you to let your uses change the VNC
server properties while the VM is running (so you change the
listening vnc display from localhost:3 to :22 without restarting the
VM).
All the above are really nice to have, but nit with the cost of
extra management overhead, as explained above.
Also, our VM life time is typically 15 minutes long... :-)
Plus, live migration has no hope of working if you're passing file
descriptors on the command line as they're meaningless once you've
migrated.
That, I have no answer for. What do you do with the Unix domain socket?
open it by path/filename on the new machines?
Gilad