The Desktop Virtualization Diaries (prologue): The Good, the Bad, and the horribly Ugly

Quite frankly, I have no idea whether I'll make it to entry #2. But the trials and tribulations of virtualizing my desktop system have been too many to chronicle in one blog post and it only seems fitting to break it up into a series of posts. I'm doing this because, for almost two years now, I've been extolling virtues of moving to a fully virtualized desktop, all along promising to practice what I preach. So, now that I'm practicing it, I find myself questioning whether I should be preaching it.

Let me clear before I start on the series. I have no regrets about virtualizing my desktop. I'm glad I did it and would do it again. I know that what I'm doing isn't exactly what the various virtualization solution providers had in mind (in other words, targeting normal PC users). But I look forward to the day when virtualizing a computer is more like driving a car with an automatic transmission rather than a stick-shift. NOT that there's anything wrong with driving a stick-shift (thanks Dad for teaching me to drive one, on a hill). It's just a little more involved than the automatic. The same goes for virtualization.

Why virtualize? Virtualizing desktops is normally the domain of software developers. It's not uncommon for a developer to use a virtualization solution like VMware, Xen, or Virtual PC to make their computer pretend as though it were actually two (or three or four) independent computers (otherwise known as virtual machines) running side-by-side without the two ever really coming into physical contact with other, unless its across the network the same way any other two systems might talk or connect to each other. Developers might for example be running a Linux-based database server in one virtual machine and a Windows based desktop in another in a way that the desktop talks to the server over a network connection. It's a great way to test client/server solutions.

But for the average Joe user, virtualization is something of enigma. They may have heard about it from a friend, seen some hype about virtualization from one of the solution providers, or caught wind of the fact that both Intel and AMD have support for virtualization built right into their consumer-targeted chips. Unlike with developers however, the benefits aren't exactly clear. One day, they will be. For now, the question is whether or not it's worth it given the investment in terms of time, aggravation and the possibility of having to re-license software you've already licensed, not to mention the fact that some things just don't work well in a virtualized environment, if they work at all.

What are those benefits? First and foremost, backing up PCs has always been something of a black art. So much so that the situation warrants specialized solutions that mask the complexity of not just backing a computer up, but restoring it when the time comes. I say "when" because that time will come. It may come when your computer breaks. All computers eventually do. It's just a question of whether you've moved on to another computer before that time comes. And that's the other time it may come.

There are lots of products on the market that specialize in migrating your old "setup" to a new system. They are, in essence, little more than specialized backup and restore programs. The problem? There's always something that doesn't come over. Maybe it's the look-ahead cache in your e-mail client (the one that auto-completes commonly used e-mail addresses before you're done entering them). Maybe it's the special way you've got your browser's security settings configured. None of migration solutions produce an exact replica of what you had before and with good reason. There's a high probability that the new system is different enough from the old system that an exact replica wouldn't work anyway.

With virtual machines, the backup and restore conundrum -- whether to recover from a catastrophic failure or to move to a new system -- is no conundrum at all. Because they themselves are based on a handful of files, backing up entire virtual machines is as simple as copying a handful of files (best done to a USB or Firewire-based hard drive). No messy directory structures to worry about. No specialized backup and restore software. In fact, as slight as the pain is, most virtualization solutions (eg: VMware, Virtual PC, etc.) manage it through a "snapshot" feature. With the click of a button, you have a snapshot of the last known state of an entire virtual machine (its operating system, applications, all your personalizations, ... everything).

Once you've got a copy of a VM (or a snapshot), that copy can be called upon at anytime and not just from the computer that created it, but rather, from any computer that can run the virtualization vendor's virtualization software (again, VMware's VMware Workstation, Microsoft's Virtual PC, etc.). I've played around with the idea of taking a VM created on one system and moving it to another. This emulates the scenario where my computer has crashed and I need to recover and I somehow manage to lay my hands on another computer. It's pretty breathtaking to see everything come back as though it had never failed in the first place, and to do so in a matter of minutes instead of the hours or days it normally takes to "rebuild."

One downside....as I said earlier, everything (your personalizations, etc.) is preserved. That includes any chronic problems your OS installation or applications may be experiencing as a result of some undiagnosed configuration problem. Some people (admittedly, I'm at time ones of them) actually relish the idea of starting with a "virgin" system.

Why else virtualize? VMs represent a great way to segregate sets of applications. For example, whereas one VM might be used to run all of your business applications, another could be for your personal life. If you're really anal about transacting online, you could have an e-commerce VM that is for nothing but conducting online transactions. Through a bit of personal firewall programming, you could make it so you e-commerce VM is incapable of communicating with domains and IP addresses other than the ones you've authorized, like your bank. I don't do this. But I can imagine a day down the road where a company like Symantec or McAfee make this into child's play.

One reason I wanted to virtualize was to solve a printing problem that I have. With most of my work being done from home, my PC is perpetually connected to CNET's corporate VPN. Unfortunately, so long as that's the case, my PC cannot connect to a printer on my local area network. To print a word document or PDF, I must first disconnect from the VPN. Then, I print the document to my local shared printer, and reconnect to the VPN. It's a pain. But with two virtualized machines running side by side, if I keep any documents that need printing in a folder that's shared between VMs (something that's supported by VMware), then I can easily flip to the non-VPN'd VM and print it from there. No messy disconnecting and reconnecting just to print a document.

OK, so you're sold on virtualization? Well, now that I've convinced you of how great it is, let me dial it back a bit by admitting it's not as great as it sounds. For close to three weeks now, I've been conducting my business and personal life on a pair of virtual machines. Each of them considered to be a "guest" virtual machine that runs atop the "host" operating system that's running on my computer the way most operating systems normally run on PCs. The computer is a Lenovo Thinkpad X60 Tablet PC. The host operating system is Windows Vista.

In some ways, if the goal is to use nothing but the virtual machines to run my life, then having Vista as the host operating system is overkill. Since I do all my work in the virtual machines and none of it on the host OS, why have all those great and in some cases resource hungry features of Vista if I'm not going to use them. Any system resources needed to run the host are also resources that won't be available to the virtual machines. I could have picked Linux as the host (VMware Workstation supports Linux as a host). But, since this X60 is a tablet, I wanted to have access to the tablet functionality in the event that I needed it.

One downside of Intel-flavored virtual machine technology is that the virtual machines tend to be pretty generic. When software is used to emulate a full-blown Intel computer as is the case with solutions like VMware, Virtual PC, and Xen, it takes certain feats of engineering to build the software equivalent of certain hardware. For example, a graphics adapter or a network port. Specialized hardware capabilities that are available to the host may not be available to the guest VMs. Tablet functionality is one of those. With some solutions like Microsoft's Virtual PC, even something as basic as USB port functionality may not be available to the guest VMs (one reason I picked VMware over Virtual PC for my setup...VMware-based virtual machines can make use of USB ports).

While the problems are not significant enough to deter me from my experiment, I do consider them significant enough to deter others from considering this as a realistic approach to computing. The problems range in complexity from the very simple (and tolerable) to quite complicated (and irreconcilable, at least for now).

Over the coming weeks, I'll write about my experiences as a part of this special diary series. But to start things off, I'll give you a taste of the sorts of things I've been bumping into right now:

As best I can tell, power management (of the sort that runs on notebook computers) and virtual machines don't mix very well. From one notebook computer to the next, the way in which power management information -- for example, how much battery life is left -- is accurately bubbled up into the Windows interface usually involves some technology that differs from one notebook manufacturer to the next. Whenever standards don't exist for certain implementations of hardware (eg: a notebook's power infrastructure), virtual machines are going to have a tough time probing those implementations for information that the end-user find useful.

So, practically speaking, what's the problem? One of the very cool things about VM technology is that if you're running multiple VMs at the same time, you can toggle between them while staying in full screen mode. In other words, if let's say, you are running Windows XP in a VM, you can run it in a way that it takes over your computer's entire display. In fact, while in the full screen mode, passers-by would probably look at your computer and think it's running XP (when in fact, the real host operating system is Vista or Linux). This is how I run my VMs. Switching between them is easy. When I press CTRL-ALT-RightArrow, my display is overtaken by the next active VM. For me, with only two VMs running, the CTRL-ALT-RightArrow keystroke is like a toggle between the two VMs. Cool, eh? (sidebar: CTRL-ALT-RightArrow is also the keystroke combination that rotates a TabletPC's screen orientation by 90 degrees. With my tablet, sometimes, CTRL-ALT-RightArrow toglgles between VMs. Other times, it rotates the screen orientation. Ugh.)

But here's the rub. If I'm running on battery power, I have no way of knowing how much battery power is left when in this full-screen mode. In fact, if I configure Windows to show me the current power status (am I operating on AC or battery power?) in the tray, it shows AC power even when I'm running on battery power.

The only way to figure it out (as best as I can tell), is to deactivate the full-screen mode so that I can see the host operating system's (Vista) desktop and tray (the latter of which shows how much battery power is left). Doing this is relatively easy. The CTRL-ALT-ENTER keystroke combination is what toggles between full screen and window modes for your VMs (when not in full-screen mode, VMs appears in a window on your Windows or Linux desktop). But it's not ideal. Sometimes, I get so engrossed in my work that I forget to check things like that (and not knowing that you're running low on battery power can be a dangerous thing). Fortunately, if you configure your host operating system to give you an audible warning that your battery is about to burn out, you can still buy yourself some time to react to a low battery. That's because the host operating system will still issue audible warnings (a subject for another post) even though a VM is taking up the entire display. But, personally speaking, I'd rather see what's happening with my system's power management infrastructure from within the VMs.

That's it for now. More to come in the next post for my Desktop Virtualization Diaries.