[ale] Mass Machine Virtualization w/ Remote GUI Access

[James P. Kinney III]

On Tue, 2006-02-21 at 15:27 -0500, Jeff Hubbs wrote:
> The 8-CPU mobo might be overdoing it but maybe not 4...
> 
> Regarding Stephen A. DuChene's comment "We have found that even using a 
> big server system with multiple GB of memory there is still a practical 
> limit of around 4 - 8 people who can run VMware sessions off of a remote 
> server," I wonder if that is caused by a RAM I/O bottleneck that the 
> RAM-affinity of those boards can help get around.  That is to say, does 
> it raise that limit or at least "soften the knee" if you're using these 
> new Opteron boards?  Or, do I just have to buy one to find out? ;)
> 
> Jeff
> 

The IO bottleneck you run into is network bandwidth. Those Tyan boards
are some serious monsters and should be the best things out that can
handle the load. Run Xen on each physical CPU and ESX on each Xen
virtual machine to partition off the server from itself.

And add some extra AC for the server :)

> Joe Knapka wrote:
> 
> >Jeff Hubbs wrote:
> >
> >  
> >
> >>I've got a situation where a number of users on a development shop LAN 
> >>are in a bad way because they're trying to run a number of different 
> >>Win2K3 Server virtual machines - done up in Microsoft Virtual PC - on 
> >>their desktops.  This has come to result in people trying to pull and 
> >>push around 4-6GB of MSVPC files on the LAN, and, of course, anyone who 
> >>wants to actually run an instance on MSVPC has to have scads of RAM and 
> >>this is often incompatible with various people's desktops and laptops 
> >>who may be running "only" 512MB, tops. 
> >>
> >>My way of addressing this would be to use VMware instead of MSVPC, 
> >>running it on an "uberserver" capable of  holding and running numerous 
> >>virtual machines at once, such that various people can connect to the 
> >>virtual machines at the display level from their own WinXP desktops and 
> >>laptops. 
> >> 
> >>
> >>    
> >>
> >Ooh, this sounds like a perfect opportunity to go out and buy some of those
> >Tyan 8-CPU mobos we were discussing last week!
> >
> >  
> >
> >>It's that last part that I have a question about.  Given that it would 
> >>be nice if more than one person could actually connect remotely to any 
> >>one of these virtual machines (i.e., fighting over mouse/keyboard if so 
> >>inclined), how to best cover the remote access?
> >>
> >>Ways I'm aware of include Xorg+Cygwin, a commercial X Server for 
> >>Windows, VNC, or MS Terminal Services. [NOTE:  I assume that all but the 
> >>last would take place over OpenSSH].
> >>
> >>What do you think?
> >> 
> >>
> >>    
> >>
> >Micro$haft wants you to pay for every terminal server connection, and if 
> >you run out,
> >you can't log into the machine at all, which is very annoying and seems 
> >to happen
> >all the freakin' time. All of our machines have VNC installed, so that 
> >we can get to
> >the machines even when folks have forgotten to log out the
> >two or three Remote Desktop sessions we're allowed on each one. I'd 
> >probably go with
> >VNC and see how that works. You might give RealVNC some money for their
> >"enterprise edition" and avoid having to muck about with SSH tunnels.
> >
> >-- JK
> >
> >
> >_______________________________________________
> >Ale mailing list
> >Ale at ale.org
> >http://www.ale.org/mailman/listinfo/ale
> >
> >  
> >
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
-- 
James P. Kinney III          \Changing the mobile computing world/
CEO & Director of Engineering \          one Linux user         /
Local Net Solutions,LLC        \           at a time.          /
770-493-8244                    \.___________________________./
http://www.localnetsolutions.com

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part