[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?




OS X uses "ScreenSharing" for VNC connections, pretty sure it's closed source, so I can't really open it up to find out how they make it work.

If anyone has any ideas I'd be willing to look into them.


On Fri, May 25, 2012 at 3:55 PM, Andrew Bobulsky <rulerof@xxxxxxxxx> wrote:
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

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.