Slashdot Mirror
Experiences with Replacing Desktops w/ VMs?
E1ven asks: "After years of dealing with broken machines, HAL incompatibility, and other Windows frustrations, I'd like to investigate moving to an entirely VM-based solution. Essentially, when an employee comes in in the morning, have them log-in, and automatically download their VM from the server. This gives the benefits of network computing, in that they can sit anywhere, if their machine breaks, we can instantly replace it, etc, and the hope is that the VM will run at near-native speeds. We have gigabit to all of the desktops, so I'm not too worried about network bandwidth, if we keep the images small. Has anyone ever tried this on a large scale? How did it work out for you? What complications did you run of that I probably haven't thought of?"
There are a lot of complications using a VM - there's no 3D, no good audio etc.. Plus if your base computer does not fit into the HAL, you can't expect much out of the VM. I am actually surprised at this - a VM will give you the benifit of portability, but if that was your goal you'd be better off giving a laptop to all your employees.
Microsoft: "You've got questions. We've got dancing paperclips."
thin client be a cheaper and easier solution per seat?
Sounds like you want something like Citrix.
Although, what you could do is automagically have a standard WinXP workstation login on startup. Next, have VMWare in the startup folder so that it begins as soon as the computer logs in. Finally, have VMWare point to a disk image loaded on your server. The employees will then see a full-screen VMWare ready to authenticate on the network and begin their day.
If you really wanted to be fancy, have that image automagically map to a network drive on your SAN/NAS as the D:\ drive. Tell employees to use the D:\ drive to store all work-related documents.
It could work. But you'd be looking at maybe 5 minutes for the morning boot-up. Not to mention all the employees hammering the network for a 2~4gb image at 7am will really thrash the servers.
If you insist on doing this, go a bit further. Activate that WoL crap and autoboot the workstations at staggered times between 6am and 7am.
I'd rather you do it wrong, than for me to have to do it at all.
http://www.vmware.com/products/enterprise_desktop. html.
Hmm. Your main issue is going to be switching machines. I see three ways of doing this:
Some virtual machines let you suspend to a file. This is nice if you must run Windows, or some other uncooperative OS. But, that still means suspend to a file, which will take some time. As for the disk, that would be fairly trivial -- your host OS would be Linux over NFS, so your disk image is an NFS file.
Issue to watch for here: Local cache. I don't care how fast your gigabit is, that server is going to feel some stress. I tried setting up gigabit just for file sharing, and it was never as fast as it should have been, yes I was using Jumbo Frames, and it's just a crossover cable, yes it was cat6. And even if that's flawless, there's the server at the other end. You probably want good local caching, probably local disk caching. InterMezzo would have been good, but they've pretty much died. You might try simply throwing tons of RAM at the problem, or you might try cachefs (never got it working, but maybe...) or maybe one of the FUSE things.
Second way: Don't use VMs. VMs will never be as fast as a native OS. But "native OS" can still work roughly the way the VM image does above, if your hardware is identical. With Linux and Suspend2, you can suspend and resume from pretty much anything you can see as a block/swap device. So, all of the above caching issues apply, but just run it as a network OS, have one range of IPs for machines still booting and logging in, and another for fully functional machines. Here, when the user logs in, the bootstrap OS tells itself to resume the OS image from the network.
You could also do this with Windows by copying a local disk image around -- after you hibernate, boot a small Linux which rsyncs the whole disk across the network, including hiberfile.sys. Everything besides the OS itself would be stored over the network already anyway (samba).
I don't know if this will work -- after all, no hardware is truly identical. But it may be worth a shot.
Advantage: Both Linux and Windows XP know to trim the image a bit on suspend, so it won't be a whole memory image, just relevant stuff. Truly native speed.
Disadvantage: If I'm wrong, then you won't be able to properly resume on a different box.
Finally, you could stick to software which supports saving sessions and resuming them. I know Gnome at least, and maybe KDE, had this idea of saving your session when you log out -- and telling all applications to do so -- so that when you log back in after a fresh boot, it's like resuming from a hibernate.
Advantages: Fastest and most space-efficient out of all of them. Least administrative overhead -- in the event of a crash, there isn't nearly as much chance for bad stuff to happen. Easily works cross-platform, native speed on any supported platform. Simplest to implement, in theory.
Disadvantage: Not really implemented. 99% of all software may remember useless things like window size and position, but very few actually store a session. If you mostly roll your own software, this may be acceptible.
And of course, you could always do web apps, but those won't be anywhere near native speed -- yet.
All approaches share one flaw, though -- bad things happen when a box goes down. With a VM image (or a suspend image), if you crash, you'll obviously want to restore from a working image -- but what about the files? If they're on a fileserver, does your working image properly reconnect to the fileserver, or does it assume it's still connected (thus having weird things cached)? The third option (saving sessions) is the safest here, because in the event of a crash, programs behave the same way they would on a single-user desktop. But you still lose your session.
What others are suggesting -- various terminal server options -- is much slower, but it also means that as long as the application server is up, so is your session. If you crash, you can switch to another machine and literally be exactly where you
Don't thank God, thank a doctor!
Folder redirection is not roaming profiles.
It uses the offline files system to smartly synchronize the files, and maintain them when you're off the network. Also, it doesn't sync the whole profile. You can configure what you want to sync.
Exactly!
This is brought to you from a SunRay at home, talking to the server in the garage...
Combined with Tarantella, you can have every Windows application you want. The latest revision of the SunRay server also works on Linux (RedHat I think)!
I run my Windows apps in QEMU, but that is because only my wife and I share the SunRay server...(2.4GHz P4, 3GB RAM). From a users perspective its just perfect! Power-on in the morning, insert your card, login and last nights session is still there. Just upgraded to the latest Open Solaris build so I had to reboot the machine, but before that my machine had reached 317 days of uptime!
In an office environment your mileage will vary, but I have always appreciated the silence of my office working on a SunRay.
Regarding the GP, downloading VM images just doesn't make sense compared to a SunRay, especially if you already have GB ethernet. Make sure the servers have enough RAM and don't let them play Quake!
(and yes, I work for Sun...)
Your goals may be better accomplished with a different approach.
Now you have most of the benefits you asked for: you can have users switch places at random, you can replace physical computers and set them all up with the same VM... you can even have them all run windows on a linux host if this helps prepare for "the big switch". :)
As for your maintenance of the VMs, you can remotely log in to any of the workstations and replace the old VMs with new ones when you need to update something. Ocasionally you can wipe out all files that are kept on workstations to ensure that no kiddie p0rn is found, and to further illustrate that it is essential to keep all work-related files on the server as instructed in 2)
Couldn't agree with you more.
It really matters what the people are doing as to what they get.
If they're doing Customer Service, sure, throw them on a Ray. Technical Support will work too, but I hope you have enough virtual applications or people that know your software pretty well. If done right, TS works fine (just keep a few windows boxes around for weird testing issues)
If they're programmers - you should really be asking them for a wishlist of what they want and then filter it out from there. Personally, I think Rays don't work too well for some programming situations due to tools required and load on the computer. Heck, I know a C++ programmer that works better on a Mac than anything else. If his productivity goes through the roof on a Mac, give the man a Mac.
The edubuntu distribution is basically a plug-n-play instant LTSP environment.
I use it for junk laptops with busted hard drive controllers. I just wish wireless network cards had boot proms, I'm using MMC/SD cards to bootstrap.
Before I part with'em: two pennies weigh ~4.996+/-0.014g, have a zinc core, and the face of Lincoln. You can keep 'em.