Re: Thin clients -- MIDRANGE-L

Loyd,

"Are you saying there would be a VM for Word, another for Acrobat, and another for Outlook?" Nope. I guess you "could" do it that way if that was necessary but I would expect that vendors would have a tool for bundling applications into a VM or offer a pre packaged VM with a set of applications. An "Office VM" for example (although MS makes too much money on OS's to go to hypervisor layer VM's). The idea is that if you package and deliver a set of applications that can't be modified or updated by the end user, you have a more secure environment. Of course you'd want to package other applications as well and perhaps in some cases you'd just go ahead and deliver a whole OS with installed applications as your VM. However, switching running VM's on a hypervisor could be easy as clicking an icon on the task bar. I switch between running VM's in XP all the time (I have Windows 98 in one VM and Linux in another) and it is quick and seamless. Of course these are running on top of an OS but there is no reason they couldn't perform the same on a hypervisor.

Copy and paste would be something to consider as you determined what to bundle together and what you could run in an individual VM. I suppose the hypervisor layer could do this. However, since this is all theoretical at the moment, we'll assume that it IS a hypervisor feature :-) That would take care of it.

Pete

lgoodbar@xxxxxxxxxxxxxx wrote:

Sorry, but ewww. Are you saying there would be a VM for Word, another
for Acrobat, and another for Outlook? And when a user clicked on a Word
attachment in Outlook, it wouldn't view because Word is on "another
computer" for all intents (not local to Outlook)? Does copy and paste
work between VMs? Not like when Windows runs multiple remote desktops -
there you rely on Windows to orchestrate the copy and paste
functionality. But at the hypervisor level?

That sounds "too secure". And we all know what a secure computer is -
powered off and unplugged in its own closet.

Loyd Goodbar
Senior programmer/analyst
BorgWarner
TS Water Valley
662-473-5713
-----Original Message-----
From: midrange-l-bounces+lgoodbar=borgwarner.com@xxxxxxxxxxxx
[mailto:midrange-l-bounces+lgoodbar=borgwarner.com@xxxxxxxxxxxx] On
Behalf Of Pete Helgren
Sent: Wednesday, September 12, 2007 14:16
To: Midrange Systems Technical Discussion
Subject: Re: Thin clients

Booth,

Actually, it is even simpler than that. The hypervisor vendor would develop a hypervisor that worked with a specific set of common hardware components. You could then boot the machine, not to an OS, but to the hypervisor itself. The hypervisor might be burned as firmware or is might boot from the network. The hypervisor would access a config file that would identify what applications are available and those applications would boot as VM's on the hypervisor layer, pulling the software off a server (similar to Citrix or other thin client applications). No local OS, no local file system (unless it was needed). So you could have a diskless workstation with just hardware, memory and CPU. Keeps things simple from a management standpoint. Yes,

if there was new hardware, the hypervisor would have to support it but you *could* also have the VM itself BE a Windows or Linux OS. Again the machine itself wouldn't be running and OS, just the hypervisor to boot the VM. So the VM could be a standalone app (like word processing) or a complete OS with installed applications. But the hypervisor is the key since it could support many VM's of different
types.

The hardware/software savings is probably not the compelling reason (unless open source projects started writing to the hypervisor layer negating the need for an OS) and you can be sure that some application vendors would still change for their apps, even if they were running on a hypervisor instead of an OS but the whole issue of management is even further simplified here. You have hypervisor and hardware. Anyone who runs on an OS (ANY OS) and that is all of us, knows that the OS contributes to some application management issues (not ALL but some). Eliminating the OS just further reduces the complexity.

Mind you, this is just an idea I have been musing over. Reality is a long way off.

Pete Helgren