[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-users] How to create a Persistent VNC connection to a VM?
Yes i agree with you as well, that however it is setup on a Mac OS X is
quite puzzling and can't imagine how they have it implanted. I am pretty
much looking for what Casey has setup using Mac OS X, but as i don't
have such a computer, i am relying on a different set of programs.
That is why i was thinking it was some settings somewhere that is
resetting the connection to the VNC client each time you do certain
things on the VM and yes it has disconnected on me a few times for
resolution changes, but mostly during reboots.
My next trial session was to try different VNC programs, such as
UltraVNC, RealVNC, and many others out there and see if they all share
the same behavior and since UltraVNC does the same thing, i guess i can
skip that one...lol. I have even tried "gvncviewer" on Debian running on
the same Dom0 that is running Xen as loopback, AND even that one resets
a lot.
Hello,
Just thought I'd chime in. I use UltraVNC on Windows to connect to
the DomU, and it doesn't have any issues with resolution changes. I
got into UltraVNC because it's open source and supports AD
authentication and various encryption methods.
It does, however, require a reconnect after DomU reboots. I had
thought that this was a side effect of the DomU ID changing upon
reboot, something with Xen stopping the VNC server and then bringing
up a new one.... but Casey's note here about the OS X VNC viewer seems
to indicate otherwise :)
Cheers,
Andrew Bobulsy
On Fri, May 25, 2012 at 2:27 PM, Shane Johnson
<sdj@xxxxxxxxxxxxxxxxxxxxxx> wrote:
I use the VNC option on all my HVM DomU's but I still have to do xm
vncviewer {host} everytime the resolution changes. which is a pain but
I can still see the entire boot process.I will usually have 3-5 run
command windows open so once it crashes, I can immediately open the
new connection to the DomU. I have only use the console option on a
PV domain for boot debugging because once the DomU is fully booted,
the console stops responding - I don't know if this is the way it's
supposed to work, but it's how mine does.
Shane
On Fri, May 25, 2012 at 11:49 AM,<cyberhawk001@xxxxxxxxx> wrote:
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?
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users
--
Shane D. Johnson
IT Administrator
Rasmussen Equipment
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users
|
