Gilad Ben-Yossef wrote:
Anthony Liguori wrote:
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
Anthony Liguori wrote:
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.
Gilad Ben-Yossef 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
Anthony Liguori wrote:
Here are the reasons why the Unix domain socket approach is superior:
Sharing a file descriptor implies a parent/child relationship.
True.
It also
implies that the daemon will be running for the entire lifetime of the
VM.
No. In fact, running an extra daemon for
On 6/26/07, Gilad Ben-Yossef [EMAIL PROTECTED] 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,
Hi Anthony,
Thanks for the feedback.
I'm afraid I'm to blame for the idea to this patch (but Shahar was the one
that actually did the real work, I'm just bothering him).
Anthony Liguori wrote:
The problem with the solution you suggest is that all VNC traffic will
be first sent to the unix
Gilad Ben-Yossef wrote:
Hi Anthony,
Thanks for the feedback.
I'm afraid I'm to blame for the idea to this patch (but Shahar was the
one
that actually did the real work, I'm just bothering him).
Anthony Liguori wrote:
The problem with the solution you suggest is that all VNC traffic
will
Gilad Ben-Yossef wrote:
If you think users other then us will use the patch (and we believe they will),
we think it'll be useful for this to be included in qemu mainline.
I have more then 100 images on one box. It would make it much easer to
write my startup scripts. :)
Background
10 host with
Shahar Livne wrote:
Hi,
I am working on a project that runs many concurrent qemu sessions with
vnc.
Handling the vnc ports for the different sessions is an issue that
also project like qemudo tries to solve.
The solution chosen there was to handle a pool of ports and manage
them internally.
Currently there is the following vnc option:
-vnc display[start a VNC server on display]
Adding the following option:
-vnc-socket sd [force VNC server on an already opened Socket Descriptor]
overrides the new socket opening for the vnc on 5900+display port, and
uses the given sd
Anthony Liguori wrote:
Shahar Livne wrote:
Hi,
I am working on a project that runs many concurrent qemu sessions
with vnc.
[..]
Adding the following option:
-vnc-socket sd [force VNC server on an already opened Socket
Descriptor]
Just redirect each port to a unique unix domain socket
Shahar Livne wrote:
Hi Anthony,
Thanks for your comment.
The problem with the solution you suggest is that all VNC traffic will
be first sent to the unix domain socket, and then copied to the TCP
socket. This double work may be acceptable if we're talking about one
instance of qemu, but as
12 matches
Mail list logo
