Vexed by Virtualization

analysis
Apr 2, 20044 mins

To compete with VMware, Microsoft must give Virtual PC users some elbow room

Last year, Microsoft’s greedy maw gobbled up the technology for Virtual PC from a small, helpless bunny of a company called Connectix. You can now purchase this technology under Redmondian shrink wrap, creatively renamed Microsoft Virtual PC 2004. Sexy, huh?

For those of us skipping back and forth between Linus and Bill, a look at Virtual PC simply leaves us scratching our heads. Why would we switch from VMware, which has been handling our Helsinki to Redmond commute for years? Sure enough, Microsoft isn’t doing such a great job of changing our minds.

For one thing, the company’s infinitely wise marketing professionals go to great lengths to avoid mentioning the other penguin operating system. So much so that they actually list OS/2 and MS-DOS on the compatibility chart but steer clear of mentioning anything else except versions of Windows. So if you’re allergic to reading manuals, it might take you some time to figure out that Virtual PC will actually support a number of additional guest operating systems, including Red Hat Linux, Novell NetWare, and even that freaky Macintosh thing. I only figured it out when I said, “Hell, it’s just a test box” and tried Red Hat 9 anyway.

So there you are, feeling strangely psyched like you just put one over on Bill by running Linux on one of his products (a feeling, by the way, that pales to the outrage that true Linux geeks feel when you run Microsoft Office on the Xandros desktop complete with simulated Windows system reboots — ha!), especially after you notice that this new “upgraded” Virtual PC actually supports fewer host platforms than the original and that it has been “re-architected to adhere to Microsoft’s stringent security standards.” I almost spewed coffee on that one. But then as you begin hacking around your virtual penguin playpen, you suddenly find something you never had under VMware — a truly isolated system.

Running VMware, my guest operating systems had full access to any peripherals attached to my host system, including SCSI and USB. Getting USB 2.0 to work with Linux can mean a tweak or two extra with that kinky kernel, but Red Hat 9 pretty much had that licked. Yet my guest in the red hat was unable to see either my attached USB printer or my SCSI-attached RAID array. This seemed so wrong that it never occurred to me it might be correct. I spent a number of frustrating hours tinkering with Red Hat, certain that it had something to do with how I’d configured the guest OS.

A quick look in the manual, however, would have told me that Virtual PC, indeed, doesn’t support USB or SCSI-attached devices for guest OSes. Only the host OS has access to these. Microsoft says there’s a way to share these peripherals by naming them as shared resources, but I was unable to make this work.

Frankly, that really kills it for me. Microsoft is billing this largely as a quality assurance and development aid — a way for programmers or IT administrators to test their work on multiple virtual platforms before releasing or deploying them. But what good is that if your virtual operating systems are so hamstrung that you’ll need to retest on a live Red Hat, Macintosh, or NetWare machine anyway?

The only areas where Virtual PC kicks VMware’s booty is in price — it’s almost 50 percent less — and in Microsoft’s iron-clad guarantee that it will work with any version of Windows. For Redmond-centric developers, that probably is a plus, but for the added functionality that VMware offers, I’ll gladly fork over the extra bucks.