VM Remote access options

VM Remote access options

[Tom Cranbrook]

Just to error test my own thinking here, there seems to be the following
options for remote graphical access to a running domian vm.  Besides the
normal network service via a port and a raw console, the options are 
straight X, VNC, and XN.

X - supports a single X window running on a local XServer, tied to a single
process on the remote system.  No remote desktop

VNC - comes in two flavors of server.  The original at&t server supports a
primative window manager and no desktop to the remote system.  A more
recent server is krfb found in the KDE tree.  This is the basis for so
called 'desktop sharing' features.  krfb forks the io on running kde
environment to the remote VNC client and thus depends on a running login
session.  It can not start a new login session.

XN - supports a remote login with a full kde desktop environement running
in a single xwindow.

Each has its advantages for specific needs.

When I mentioned bad performance of XN in an earlier post, I was refering
to test on a xen domain.   Over a regular network, it is quite snappy, and
over the internet, it is simple amazing.  It does not seem to be happy on a
domain system, however.  I've got some more things to try.  But the client
is gagging and stops responding after a connection has been established and
a session started.

The top command shows several new items in the cpu summary display for a
running domain, labeled wa, hi, and si.  Can't find any docs refs to them. 
Know want those are?

  





-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: VM Remote access options

[Ian Pratt]

> Just to error test my own thinking here, there seems to be the following
> options for remote graphical access to a running domian vm.  Besides the
> normal network service via a port and a raw console, the options are 
> straight X, VNC, and XN.
> 
> X - supports a single X window running on a local XServer, tied to a single
> process on the remote system.  No remote desktop

Checkout the Xnest server. It allows you to run an Xserver
displaying to an Xwindow (which can be full screen).

> VNC - comes in two flavors of server.  The original at&t server supports a
> primative window manager and no desktop to the remote system.  A more
> recent server is krfb found in the KDE tree.  This is the basis for so
> called 'desktop sharing' features.  krfb forks the io on running kde
> environment to the remote VNC client and thus depends on a running login
> session.  It can not start a new login session.

RealVNC seems to work well. I suspect you can elide the login
session issue with a suitable script.

> When I mentioned bad performance of XN in an earlier post, I was refering
> to test on a xen domain.   Over a regular network, it is quite snappy, and
> over the internet, it is simple amazing.  It does not seem to be happy on a
> domain system, however.  I've got some more things to try.  But the client
> is gagging and stops responding after a connection has been established and
> a session started.

I'm not sure why it would have problems -- it's just using a TCP
connection, right?

Ian


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: VM Remote access options

[Mark A. Williamson]

> > VNC - comes in two flavors of server.  The original at&t server supports
> > a primative window manager and no desktop to the remote system.

The RealVNC / TightVNC servers start an X server that outputs directly to the 
VNC server and onto the network.  There is no physical display device (which 
you couldn't have anyhow in dom != 0).  You can disconnect and connect to 
this session and it will persist in the meantime.  You can also have multiple 
users connected.

The vncserver command may start a nasty window manager for you but there's 
some VNC configuration file you can use to change this and run KDE.  We've 
run KDE over TightVNC and found it works great.

It's efficient because VNC *is* the display device and doesn't have to 
screen-scrape.  Also, it can start a new X-windows session.

> > A more 
> > recent server is krfb found in the KDE tree.  This is the basis for so
> > called 'desktop sharing' features.  krfb forks the io on running kde
> > environment to the remote VNC client and thus depends on a running login
> > session.  It can not start a new login session.

The krfb is nice but (currently) has to poll the screen for updates, and is 
thus less efficient than the aforementioned server.  Future advances in the X 
server should eliminate this, however.

The krdc client is nicer than the standard VNC client.

Gnome 2.8 also has this feature and there's an X server mod on Sourceforge 
that'll give you this for any desktop you want, with the added bonus of 
avoiding screen scraping.  Again, only useful if you have an existing 
session.

> > When I mentioned bad performance of XN in an earlier post, I was refering
> > to test on a xen domain.   Over a regular network, it is quite snappy,
> > and over the internet, it is simple amazing.  It does not seem to be
> > happy on a domain system, however.

It probably should perform OK.  The forwarding of sound, printing, etc are 
also cool and not offered by the alternatives.  I take it this is using the 
commercial NX server?

Cheers,
Mark


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: VM Remote access options

[Michael Vrable]

On Tue, Sep 28, 2004 at 11:45:39AM -0400, Tom Cranbrook wrote:
> The top command shows several new items in the cpu summary display for a
> running domain, labeled wa, hi, and si.  Can't find any docs refs to them. 
> Know want those are?

wa = I/O wait; time when the CPU is idle but a process is blocked
     waiting for data
hi = hardware interrupts
si = softirq interrupts

(A bit of digging turned up help in Documentation/filesystems/proc.txt
in the kernel source tree.  Look in the section "1.8 Miscellaneous
kernel statistics in /proc/stat".)

--Michael Vrable


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: VM Remote access options

[Tom Cranbrook]

>
>> When I mentioned bad performance of XN in an earlier post, I was
refering
>> to test on a xen domain.   Over a regular network, it is quite snappy,
and
>> over the internet, it is simple amazing.  It does not seem to be happy
on a
>> domain system, however.  I've got some more things to try.  But the
client
>> is gagging and stops responding after a connection has been established
and
>> a session started.
>
>I'm not sure why it would have problems -- it's just using a TCP
>connection, right?
>

My understanding is that it runs through an ssh tunnel.  Weither its using
tcp or dhp, I'm not sure.






-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: VM Remote access options

[Tom Cranbrook]

>
>It probably should perform OK.  The forwarding of sound, printing, etc are

>also cool and not offered by the alternatives.  I take it this is using
the 
>commercial NX server?
>

No, I'm using the freeXNserver from  www.kalyxo.org.







-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: VM Remote access options

[Mark A. Williamson]

> No, I'm using the freeXNserver from  www.kalyxo.org.

But the nomachine client?  I can't see much evidence that the free kNX is 
available anywhere right now.

Are you in a position to try one of the evaluation versions of the commercial 
server, just to check that it's not FreeNX being weird?

I have just downloaded a copy of FreeNX but it doesn't like me at the moment, 
it seems!

Cheers,
Mark


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl