@Mike

Mouse tracking can be handled by an X-Windows proxy such as lbx (low
bandwidth X).

@Rob

What would you estimate the cpu/memory requirements for 1000 desktop users?

Matthew

On Thu, May 14, 2009 at 11:50 PM, Ward, Mike S <[email protected]> wrote:

> Thanks to all who have replied. All, do linux users use a mouse. I would
> think that mouse tracking would be a nightmare in the VM environment. I
> remember way back when we used to ask users monitoring jobs in OS/VS1 to
> not hit the enter key constantly. It's ok for a few, but when you have
> 5,000 connected to an opsys running under VM, at least the old releases
> it became a problem.
>
> -----Original Message-----
> From: The IBM z/VM Operating System [mailto:[email protected]] On
> Behalf Of Rob van der Heij
> Sent: Thursday, May 14, 2009 6:51 AM
> To: [email protected]
> Subject: Re: Virtualized Desktop
>
> On Wed, May 13, 2009 at 10:28 PM, Ward, Mike S <[email protected]> wrote:
>
> > Since SLED is an Enterprise Desktop, does that mean you would have to
> > have one SLED for every user under VM?
>
> My approach would be indeed to run just one desktop per virtual
> machine, instead of what Matthew suggested with all desktops on a few
> Linux virtual machines. My preference would be the simplifier security
> issues and the ability to ensure that resources can be granted to the
> virtual desktop that is supposed to use them, and the ability to
> charge for consumed resources.
>
> Something to think about is whether the virtual machine needs to be
> there when the user is not. One of my pet projects was to speed up
> Linux boot process so that we could start the virtual machine when the
> first TCP/IP packet arrives (and get it done within the time that
> TCP/IP allows you).  I even worked with a customer who considered to
> migrate unused virtual machines to tape and restore them when needed
> (and accept that it may keep the developer waiting for a few minutes).
>
> Clearly you want something to share the program code so that you can
> do software management in a central manner and not upgrade each
> virtual server separately. That requires you separate data from
> (centrally managed) code and server configuration.
> When you review the thread about "stateless Linux" on the list
> yesterday, it appears an attractive approach to have a small supply of
> "luke warm" Linux servers ready to get personalized when the user
> attempts to connect to the desktop. It would require their data and
> configuration to reside on a separate file server. I would be tempted
> to hibernate to disk rather than RAM (and expect z/VM paging to
> restore it) but either approach might work.
>
> Rob
> --
> Rob van der Heij
> Velocity Software
> http://www.velocitysoftware.com/
> ==========================
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity
> to which they are addressed. If you have received this email in error
> please notify the system manager. This message
> contains confidential information and is intended only for the individual
> named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail. Please notify the
> sender immediately by e-mail if you
> have received this e-mail by mistake and delete this e-mail from your
> system. If you are not the intended recipient
> you are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this
> information is strictly prohibited.
>
>

Reply via email to