Windows Virtual PC: Good, bad, ugly

On the same day Microsoft released the Windows 7 RC to MSDN and TechNet subscribers, it also released a beta of Windows Virtual PC and Windows XP Mode. The former is almost, but not quite, entirely unlike the Virtual PC you already know. The latter is an installable virtual machine that contains a licensed copy of Windows XP. Put the two together and you have a no-cost workaround for almost any compatibility problems between “old” software that works correctly on Windows XP but not Windows Vista or Windows 7.

You might already be using Hyper-V, Microsoft’s hypervisor-based, take-no-prisoners/competitors server virtualization technology. Personally, I prefer using a client OS, especially when working with technologies like WPF. I also prefer client virtualization products because they tend to have convenience features like drag-n-drop of files from the host machine to the virtual machine. Server virtualization products tend to lose convenience features because they’re meant to be run from headless servers locked away in an air-conditioned server room.

However, convenience aside, for developers, the new-and-improved-with-Windows-prefix Virtual PC has its share of good, bad, and ugly.

Good (maybe even great)

New features are almost always good, especially when other products have them (or maybe especially when they don’t).

  • Virtual PC now supports USB. That means you can attach USB devices to a virtual machine. The most common I’ve heard requested are smart cards and media players. (Hyper-V doesn’t support USB.)
  • Virtual PC now uses multiple threads. That means multiple VMs will use multiple cores instead of round-robining on a single core.
  • Virtual PC can now be automated. That means it’s now feasible to build tools on top of Virtual PC, which didn’t have an automation interface in the past. Unfortunately, it’s a COM API so it’s not the perfect managed-code interface, but it’ll do.

Bad (or at least disappointing)

Existing limitations that weren’t lifted when you really hoped they would be: yeah, generally considered “bad.”

  • Virtual machines are limited to one virtual processor. Hyper-V supports multiple virtual CPUs per virtual machine. Anyone expecting the next version of Microsoft’s desktop virtualization technology to also support multiple virtual CPUs is probably disappointed.
  • 64-bit virtual machines aren’t supported: Hyper-V supports running 64-bit OSes in VMs. Virtual PC: not so much. Given that Windows Server 2008 R2 is Microsoft’s first server OS that comes only in 64-bit flavors, the windows for 32-bit-only virtualization is closing fast, so this limitation is definitely disappointing.

Ugly (but probably unimportant)

Luckily, “ugly” here is limited and provisional. It won’t even matter to most people.

Virtual PC now requires hardware-assisted virtualization. Previous versions of Virtual PC took advantage of Intel VT and AMD-V hardware-assisted virtualization if it was available. Now it’s required. As a practical matter, most x86/x64 CPUs shipped for the past two or three years support hardware-assisted virtualization. However, Intel has frequently made available varieties of its CPU lines and one of the differentiators has been VT support. For example, when the first Intel quad-core CPUs shipped, they all had VT; now:

Contrast with the latest-and-greatest:

and the server/workstation line of Xeon CPUs:

Suggestion: Always check with Intel’s Processor Spec Finder Web site to make sure that the CPU in the machine you’re considering supports VT. Use Intel’s Processor Identification Utility to check for the VT feature. If you’re buying configurable hardware, check the available upgrades: You might be able to get a CPU with VT as a cheap upgrade. And if you already have a CPU without VT, well, a new machine could both get you hardware-assisted virtualization and help stimulate the economy.

What have you done for me lately?

For developers and testers, Windows Virtual PC is a nice upgrade. Automation and multiple threads are big wins for testing. But the lack of 64-bit VM support is a major drawback with the soon-to-be-current version of Windows Server 2008 R2 being available only in 64-bit versions. Even for teams doing nothing but client-OS development, testing products on x64 OSes is vital.

Clearly, however, this version of Virtual PC was focused on providing Windows XP Mode. I’ll hold on to hope that, flush with that success, management will encourage the Virtual PC team (with the carrot-and-stick-but-mostly-stick approach) to give developers and testers more virtualization love.

Virtual PC and Virtual Server now support latest Windows

Virtualization products are low-level programs, pretty much by definition. They have drivers and often poke and prod both the host and guest OSes to perform better. That means they’re sensitive to changes in the OS from service packs. The recent releases of XP SP3, Vista SP1, and Windows 2008 Server have now been matched with updates for both Virtual PC and Virtual Server.

The Virtual PC service pack is delivered as a major upgrade while the Virtual Server update is delivered as a raw .msp patch. That’s pretty unusual; most patches are delivered as self-extractors to manage the elevation, properties of the patch installation, and UI. The Virtual Server folks got most of it covered but one, based on the following instruction on the download page:

Note: Save the MSP file locally and Run the patch from an elevated command window in Windows Vista SP1 and Windows Server 2008

Unfortunately, instructions on download pages are soon forgotten, as you’ll undoubtedly agree if you’ve spent time in tech support. One of the most important things setup can do is prevent common user error. Given that the patch is three-quarters the size of the original release, releasing the Virtual Server update as a major upgrade like they did for Virtual PC would have taken care of the elevation problem in one fell swoop.

[via Virtual PC Guy]