We've previously discussed various virtual machine solutions available for Windows including both VMWare and Connectix (The NT Insider, January-February 2002). Shortly after acquiring Connectix, Microsoft released "Virtual PC 2004". Our view of VirtualPC is that it suffers from many of the same failings as the Connectix product did - most notably the performance lacks that of the VMWare offering. On the plus side, one benefit to Virtual PC is its support for kernel debugging.
Recently, folks at Microsoft have been singing the praises of "Virtual Server" a new product (currently available for download from the MSDN download site, with appropriate level of membership, of course). We've started playing with it here at OSR - and our initial impressions are favorable.
The Feature Set
The number one improvement is clearly performance - most noticeable when you go through the inevitable installation step. The other obvious change is the administration interface, which is entirely IIS based. If you want to run this on your workstation class system (like Windows XP) then you will need to install the IIS server component before installing Virtual Server. From reading the documentation, the rationale for this appears to be that the primary target for Virtual Server is both being hosted on and hosting the server class operating systems (be it Windows 2000 Server or Windows Server 2003). The documentation does not even mention workstation operating systems (Windows XP) nor did we get a chance to try that configuration out prior to press time.
One advantage of the administration interface being hosted on IIS is that all you need to manage a Virtual Server installation is Internet Explorer - it does require an ActiveX control that must be installed, and it complains bitterly if your connection to the IIS server is not secured with an SSL certificate, but it seems happy to use an internally generated certificate (assuming you have set up a Certification Authority).
From the initial configuration screen you can choose to administer a different server, connect to an existing running virtual machine, create a new virtual hard disk, or create a new virtual network.
Individual machines can be configured with a variety of virtual devices - it comes standard with two IDE controllers, a variable amount of memory (generally up to about 80% of the physical memory on the computer system), and a virtual CD drive that can be connected to a physical CD (or DVD) drive, or redirected to an ISO image. The ISO image option is nice for those of us using the downloaded ISO images from MSDN. One disadvantage that I found with using ISO images is that I have an existing library of such images, and in order to use them, I had to type in the full path name to their location - there's no browse dialog to ease that process. This limitation also applied when I wanted to create a second virtual hard disk drive - I had to manually type in the entire path to its location because I wanted to store it to a different location on my system.
Configuring a new machine is actually pretty simple. Choose "Create" from the main control menu. You are then presented with a menu of choices.
You can choose a name for your new Virtual Server, configure it with some memory (default is 128MB), and establish the size of the new virtual hard disk (this is a maximum size, not a pre-allocated size. The initial hard disk is about 40KB in size, but grows quickly once you install the OS into it). Finally, you need to decide how you want this to appear on the network - you can assign no network (a bad choice for server platforms usually), you can associate it with an internal (local to this machine) network, or bind to one of the attached physical network cards on the system. This can be convenient when testing of networking software (for instance), but don't expect activation over the internet to work very well if you are connected to a "local to this machine" network!
Having completed the small list of choices, click on OK and you are now presented with your new virtual machine!
The Reality of Virtual Server
As with Virtual PC, the Virtual Server product does not have any virtual USB ports. This is unfortunate, since it can be useful to connect (and test) USB hardware within a virtual machine environment, rather than requiring a physical machine. Thus, if USB support is still a requirement for your virtual machines, the Microsoft offerings are not going to meet your needs. For debugging purposes, you can use the serial port attached to a named pipe. Details of how to establish the debugger end of this connection are in the documentation for the current debugger.
The documentation for Virtual Server hints at some of the rather interesting features supported within the server environment itself - support for connection via a SAN, for example. One nice feature (from the testing perspective) is that you can actually configure two virtual machines to run in a clustered configuration - substantially easing the testing of what is, (generally speaking), a rather demanding configuration to set up and test. The documentation clearly says that this is for testing and training only and should not be used to provide reliability in "real world" environments.
Many of the features available for Virtual Server are geared towards use in production environments - support for up to 3.6GB of memory within a virtual machine, resource management, etc. Surprisingly, Virtual Server does not appear to provide support for virtual multiprocessor machines, giving the VMWare virtual server product an edge up. Of course, for those of us developing and testing software, it means we still must use real computers to test - we can't ship it without considerable testing and exposure on SMP.
For both Virtual Server 2005 and VMWare, an emerging challenge is how to deal with the newer 64-bit processor platforms. With AMD shipping and Intel planning to ship 64-bit variants of their processors, more and more machines will begin to use these new 64-bit platforms. Neither product currently supports AMD-64 in long mode, probably due to AMD's decision not to provide hardware virtual machine support. No doubt over the next year or two this is an area that will need to be addressed.
Red Pill or Blue Pill?
For those developers who have an existing MSDN subscription and need to do server-level testing, Virtual Server 2005 is definitely worth considering. Its performance is much improved over Virtual PC, although still a bit slower than VMWare and there's no additional cost in using it. Around here, we'll likely continue using a variety of different virtual solutions for the foreseeable future - Virtual Server is terrific, but so is VMWare and it supports Windows XP as well as the sever platforms.