Xen users - May 2012 - How to create a Persistent VNC connection to a VM?

Hopefully this is a very simple thing to answer, BUT I have one computer 
running Xen 4.2-unstable and once you create a VM using the "xl
create"
command, it creates that VM as well as opens a new VNC port to it.

I than use TightVNC from a second computer running WInXP to connect to 
the newly created VM on the server.

Now, my question is that as that VNC connections disconnects a LOT 
during the process of reboots and doing updates and etc and have to 
reconnect so often, HOW to or is there a simple way to create a 
persistent VNC connection to the VM no matter what it is doing as long 
as you do not run the "xl destroy" command on the server, you will
still
see the VM Console?

Does such a thing have to do with some setting on the Xen server? or it 
is something with the TightVNC program running on WinXP that is making 
it disconnect?

From what I have seen - it''s a limitation of VNC with resolution
changes.
 I see the same behavior if I resize a Windows desktop.  I''ve never
found a
way to circumvent it.


Shane

On Thu, May 24, 2012 at 2:54 PM, <cyberhawk001@gmail.com> wrote:
> Hopefully this is a very simple thing to answer, BUT I have one computer
> running Xen 4.2-unstable and once you create a VM using the "xl
create"
> command, it creates that VM as well as opens a new VNC port to it.
>
> I than use TightVNC from a second computer running WInXP to connect to the
> newly created VM on the server.
>
> Now, my question is that as that VNC connections disconnects a LOT during
> the process of reboots and doing updates and etc and have to reconnect so
> often, HOW to or is there a simple way to create a persistent VNC
> connection to the VM no matter what it is doing as long as you do not run
> the "xl destroy" command on the server, you will still see the VM
Console?
>
> Does such a thing have to do with some setting on the Xen server? or it is
> something with the TightVNC program running on WinXP that is making it
> disconnect?
>
> ______________________________**_________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>


-- 
Shane D. Johnson
IT Administrator
Rasmussen Equipment


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

I think your best bet would be to write a proxy server that keeps the VNC
client''s connection open and periodically attempts to reconnect to the
VNC
server when the server goes down.  The VNC protocol is actually really
simple, so you could probably implement one without that much difficulty.

On Thu, May 24, 2012 at 4:54 PM, <cyberhawk001@gmail.com> wrote:
> Hopefully this is a very simple thing to answer, BUT I have one computer
> running Xen 4.2-unstable and once you create a VM using the "xl
create"
> command, it creates that VM as well as opens a new VNC port to it.
>
> I than use TightVNC from a second computer running WInXP to connect to the
> newly created VM on the server.
>
> Now, my question is that as that VNC connections disconnects a LOT during
> the process of reboots and doing updates and etc and have to reconnect so
> often, HOW to or is there a simple way to create a persistent VNC
> connection to the VM no matter what it is doing as long as you do not run
> the "xl destroy" command on the server, you will still see the VM
Console?
>
> Does such a thing have to do with some setting on the Xen server? or it is
> something with the TightVNC program running on WinXP that is making it
> disconnect?
>
> ______________________________**_________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>

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

From my experiences it has nothing to do with the Server side of the
connection.

Gnome VNC Viewer (gvncviewer) and OS X ScreenSharing do not crash on window
resize, the built in and xtightvncviewer seem to however.

Also, OS X Screen Sharing (launched from terminal "open
vnc://ip:display")
requires the server to be up to establish the first connection, but
afterwards I can reboot the virtual machine as many times as I want and the
VNC Client Window remains open throughout the entire process.

To me this either means many of the VNC Clients lack in functionality, or
haven''t well documented these features.


~Casey

On Thu, May 24, 2012 at 5:02 PM, John Sherwood <jrs@vt.edu> wrote:
> I think your best bet would be to write a proxy server that keeps the VNC
> client''s connection open and periodically attempts to reconnect to
the VNC
> server when the server goes down.  The VNC protocol is actually really
> simple, so you could probably implement one without that much difficulty.
>
>
> On Thu, May 24, 2012 at 4:54 PM, <cyberhawk001@gmail.com> wrote:
>
>> Hopefully this is a very simple thing to answer, BUT I have one
computer
>> running Xen 4.2-unstable and once you create a VM using the "xl
create"
>> command, it creates that VM as well as opens a new VNC port to it.
>>
>> I than use TightVNC from a second computer running WInXP to connect to
>> the newly created VM on the server.
>>
>> Now, my question is that as that VNC connections disconnects a LOT
during
>> the process of reboots and doing updates and etc and have to reconnect
so
>> often, HOW to or is there a simple way to create a persistent VNC
>> connection to the VM no matter what it is doing as long as you do not
run
>> the "xl destroy" command on the server, you will still see
the VM Console?
>>
>> Does such a thing have to do with some setting on the Xen server? or it
>> is something with the TightVNC program running on WinXP that is making
it
>> disconnect?
>>
>> ______________________________**_________________
>> Xen-users mailing list
>> Xen-users@lists.xen.org
>> http://lists.xen.org/xen-users
>>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>

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

> 
> I think your best bet would be to write a proxy server that keeps the VNC
> client''s connection open and periodically attempts to reconnect to
the VNC
> server when the server goes down.  The VNC protocol is actually really
> simple, so you could probably implement one without that much difficulty.
> 
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.

I also can''t remember how the password authentication works in the
reverse connection mode... ideally the client and server would have to
authenticate with each other but having the server authenticate to the proxy
would be sufficient. Anything else would be a security hole.

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.

James

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).

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

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@lists.xen.org
http://lists.xen.org/xen-users

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@gmail.com>
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@lists.xen.org
> http://lists.xen.org/xen-users



--
Shane D. Johnson
IT Administrator
Rasmussen Equipment

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@rasmussenequipment.com> 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@gmail.com> 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@lists.xen.org
>> http://lists.xen.org/xen-users
>
>
>
>
> --
> Shane D. Johnson
> IT Administrator
> Rasmussen Equipment
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users

cyberhawk001@gmail.com wrote:
>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 mean exactly - connect directly to the guest machine. Run whatever 
software your (unspecified) guest OS needs in order to provide it''s 
own GUI via <your choice of remote viewer>.

For Linux, you can setup an X server to provide a VNC connection. For 
Windows you''d be better with Remote Desktop than VNC - it passes 
display primitives (eg "draw a rectangle") rather than passing a 
bitmap of the result, and works very well with less bandwidth.

In both cases you''ll have remote access to the machine once it has 
booted. Getting access to a booting machine will require you to use 
the VNC (or text) console provided by the host.

Personally, for a Linux guest I''d not run a graphical console.
I''d
use a text based console.
-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

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@rasmussenequipment.com>  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@gmail.com>  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@lists.xen.org
>>> http://lists.xen.org/xen-users
>>
>>
>>
>> --
>> Shane D. Johnson
>> IT Administrator
>> Rasmussen Equipment
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xen.org
>> http://lists.xen.org/xen-users

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@gmail.com>
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@rasmussenequipment.com> 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@gmail.com>
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@lists.xen.org
> >> http://lists.xen.org/xen-users
> >
> >
> >
> >
> > --
> > Shane D. Johnson
> > IT Administrator
> > Rasmussen Equipment
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xen.org
> > http://lists.xen.org/xen-users
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>

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

2012/5/25 Andrew Bobulsky <rulerof@gmail.com>:
> 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.
Cool, maybe I should try that...
> 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
There''s two things happening on the reboot.
1. The VNC server process for the VM is destroyed (and this sucks)
2. The domU ID changes, resulting in a new vnc port

You can fix 2) with static vnc port numbers, using vncunused=0 and then
setting them correctly.
Of course, then you need to know the port number, but once you connect
to more than one VM at the same time this would be neccessary anyway.

Once the port stays the same your VNC client might be able to keep the
session going over the problems caused by 1)

If you don''t require VNC in the VM itself, another nice option is to
use iptables
or ebtables in dom0 to just forward the session to the domU. I haven''t
done that
but I''m quite sure it will work.

For us, things got a lot better since we have fixed VNC port numbers
for all VMs.
We only need VNC since xm console is quite limited and won''t let you
access the
vty 2-4 of a guest, and we needed those for kickstart debugging.

Greetings,
Florian