On 5/25/2012 3:05 AM, Simon Hobson wrote:
James Harper wrote:
I was actually looking into this a little
while back. One thing I decided though was that qemu would need
to make a 'reverse vnc' connection so that it connects to the
proxy as the server, which would remove the need for the proxy
to poll the server (or even know which physical server IP the
client was running on). For some reason though, qemu has its own
implementation of vnc rather than using libvnc (or whatever it
is called), so this change is more than a one-liner, although
maybe still not that difficult.
...
The other advantage of this for me is that
in a cluster of physical machines where the VM's float around
depending on load etc, they all still just connect to the same
proxy.
Would it be better to connect to the guest machine itself ? Ie set
up the machine to run a shared virtual desktop rather than the
virtual console display ?
That way, you never need to know where the guest is (ie which host
it's on, or which port it's console is on), you just connect to
it's IP address and it'll just work (as long as it's actually up
at the time).
------------- ------------- -------------
What do you mean by "connect to the guest machine itself"? By guest
machine you mean the Guest VM (aka DomU), or you mean the Host
Machine (aka host server or Dom0)?
I was really hoping not have to try things like trying to write my
own proxy server and etc. But, I have also heard about a "reverse
vnc" and i think it could be what TightVNC calls a "listening" mode
that you can select when you run the VNC Client. I guess most VNC
clients have this option, BUT not figured out how it even works or
how to use it yet.
I guess one option would be something like what is written here
http://www.realvnc.com/products/viewerplus/index.html This VNC
client uses the Intel Active Management Technology (AMT 6.0+) that
is located on some Intel motherboards that, as the article states,
"...enabling permanent remote access and control...". But, that is
just one option if you have that type of motherboard.
I was also looking in the "xl" command man page, and under in
there it says:
------------- ------------- -------------
create [configfile] [OPTIONS]
OPTIONS
-V, --vncviewer ## Attach to domain's VNC server,
forking a vncviewer process.
-A, --vncviewer-autopass ## Pass VNC password to vncviewer
via stdin.
-c ## Attach console to the domain as soon as it has
started. This is useful for determining issues with crashing domains
and just as a general convenience since you often want to watch the
domain boot.
------------- ------------- -------------
At first glance i thought the --vncviewer option allows you
to connect the VNC server started once VM is created and attach it
to the Dom0 VNC server (assuming you have on installed and running
as there is not one by default), GRANTED not even sure what they
mean by "forking a vncviewer process". BUT, i am sure that is
not how that works at all, so it was merely a snappy thought.
Which also brings up another question. Since there are a lot of VNC
type options under the vfb=[' ', ' '] option in the DomU
Configuration options, does the vfb=[ ] option only works
with PV type DomU's, such as Linux types, AND will not work with HVM
guests such as Windows?
|
