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 e
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 opt
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
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
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
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
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 d
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 I
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 an
Paul Brook wrote:
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 g
> 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 s
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.
S
13 matches
Mail list logo