Virtual-Server Face-Off

Here another comparison between VMware and Microsoft virtualization products. Quoting from WindowsITPRo:

The year 2004 might very well become known as the year of virtualization. Initially, IT pros recognized the value of virtualization technologies in test and demo environments. However, with the advent of ever more powerful systems coupled with continued improvements in virtual machine (VM) technologies, virtualization has since become a production-level technology that enables server consolidation.

VMware was first to market in the virtualization space with the release of VMware GSX Server in 2001. In October 2004, Microsoft entered the virtualization market with Virtual Server 2005, sparking much interest, especially among customers who have come to rely on VM technologies. A comparison of these two titans of virtualization leads to a clear recommendation as to the product that can best address a particular organization’s needs.

The VM Architecture
Both products install on top of the base OS and provide a software layer that emulates a physical system. You can install a guest OS on each emulated system, or VM, and you can run multiple VMs concurrently as if each were installed on a separate physical system.

Each VM owns its own virtual hardware, consisting of a processor, disk, memory, and network. VMs aren’t aware of other VMs as anything other than networked systems. The virtual server product handles the task of virtualizing the hardware and sharing it with all the VMs. The virtual server also provides virtual networking services that can connect VMs together as well as giving them access to external network resources.

Review Criteria
Although both products possess similar overall functionality, they also have several significant differences. In evaluating the products, the first criterion I considered was the host and guest OSs they support. The host OSs are the OS platforms on which you can install the VM software. The guest OSs are the OSs that the virtual servers can run. I also compared ease of use and overall manageability, looking at the process of creating new VMs as well as the ability to manage the virtual server and the VMs.

Finally, I compared the performance of the VMs running under each product. To check the overall performance of the guest OSs, I used SiSoftware Sandra 2005 Lite benchmarking software ( I compared the results of tests run on the VM that I created on each virtual server—a vanilla installation of Windows Server 2003, Enterprise Edition—to the results of baseline tests I ran on the physical machine. I performed all tests on an HP ProLiant ML350 with dual Intel Xeon 3.2GHz processors, 2GB of RAM, and a dual-channel Ultra320 SCSI controller connected to four 36GB, 15,000rpm hard drives running Windows 2003 as the host OS.

Microsoft Virtual Server 2005
Microsoft makes two versions of Virtual Server 2005: Standard Edition and Enterprise Edition. Standard Edition supports host servers with up to 4 processors; Enterprise Edition supports host servers that have as many as 32 processors. However, the product doesn’t provide SMP support for the VMs running on a Virtual Server 2005 server.

By using Physical Address Extension (PAE), Virtual Server can support up to 64GB of memory, and each VM can address up to 3.6GB of memory. Both versions support a maximum of 64 VMs per host. Microsoft supports Virtual Server for use only on 32-bit host platforms.

Unsurprisingly, Virtual Server supports only Microsoft host and guest OSs. Although I used the product to run other OSs, such as Linux, I don’t recommend that you do so in a production environment because of the lack of support.

I’m accustomed to using Microsoft Virtual PC, but Virtual Server is a very different animal and took a little getting used to. Instead of using a Windows-based management console, you manage Virtual Server through the Administration Website console that you see in Figure 1. You access the management program either by selecting the Administration Website option on the Virtual Server 2005 server or by pointing a browser to http://server:1024/VirtualServer/VSWebApp.exe.

Although it took a while for me to feel comfortable with it, the console made it very easy to manage Virtual Server from across the network. The Administration Website provides a thorough overview of the status of the configured VMs, including current performance data and even a mini screen view. I appreciated the no-footprint management offered by the Administration Website, but unfortunately the price you pay for it is having to run IIS 6.0 on the host. The installation process automatically configures IIS, adds the Administration Website, and sets permissions for the site, but you still have an extra element to manage.

Unlike GSX Server, Virtual Server has no wizard to step you through the process of creating VMs. Instead, you need to use the links provided by the Administration Website to manually create a virtual hard disk (VHD), a virtual network, and a VM that utilizes the VHD and virtual network. After I became familiar with the process, I found the interface fairly easy to navigate, but it lacked some of the niceties that I’ve come to expect from a Windows application, such as the ability to browse the file system when creating VHDs. I like the Administration Website’s ability to provide remote control for all the VMs. After you create a VM, you’ll probably want to install the Virtual Machine Additions, software drivers that increase screen resolution by adding an SVGA driver and enable better mouse tracking and control.

Virtual Server supports four types of VHDs: dynamically expanding, fixed-size, differencing, and linked. The host OS sees dynamically expanding and fixed-size VHDs as a large .vhd file that contains the file system for the guest VM. Dynamically expanding disks start small and automatically grow as the guest VM requires additional storage. Much like a physical hard drive, a dynamically expanding disk can grow only until it reaches its predefined limit. As you’d expect, the guest VM experiences a delay when the VHD must be expanded. Fixed-size VHDs are allocated when you create them and don’t grow.

Dynamically expanding, fixed-size, and differencing VHDs support using an optional undo disk. Undo disks let you reset all changes that have been made to a dynamic, fixed-size, or differencing disk. Undo disks store all configuration and data changes made to the VM during the session and prompt you to save or discard the changes when you shut down the VM. Differencing disks let you isolate changes that occur within a guest VHD; all changes that occur in the parent VHD are stored in the differencing disk. Unlike an undo disk, which is associated with the entire VM, a differencing disk is associated with a particular VHD. Compared with GSX Server’s differencing disks, Virtual Server’s built-in differencing disks are a snap to create.

Linked VHDs are different from the other types of VHDs. Linked disks convert an entire host file system’s partition to a VHD. Afterward, the host can no longer access that portion of the file system. You can’t use linked disks with undo disks or differencing disks.

You can configure virtual networking to use either the host system’s NIC or a user-defined virtual network that only VMs can access. If you use the host NIC, any VM connected to the virtual network can access the network that the host is connected to. Otherwise, the VM can access only the internal virtual network. Virtual Server can also provide a virtual DHCP server, so you don’t need to configure a guest VM on an internal network to act as a DCHP server.

One especially nice feature is Virtual Server’s ability to configure shared SCSI VHDs, which lets you set up Microsoft Cluster service over two VM nodes. Another welcome feature is the ability to transfer VMs created with Virtual PC 2004 to Virtual Server. One annoying limitation of Virtual Server is that, like Virtual PC, it lacks support for USB devices. Although you can use USB keyboards and mouse devices, you can’t plug in USB flash drives with Virtual Server and have them recognized in the VMs. Virtual Server also has a strong set of COM-based APIs that you can use in conjunction with VBScript to create your own custom management scripts.

Microsoft offers the Virtual Server Migration Toolkit (VSMT) as a free add-on to Virtual Server. Available for download at, the VSMT can convert physical machines to VMs and VMware VMs to Virtual Server–compatible VMs. VMware offers a similar product, called the VMware P2V Assistant, but you must purchase it separately.

VMware GSX Server 3.1
Now in its third release, VMware GSX Server offers two licensing levels: one for systems with one or two CPUs, and the other for systems with up to 32 CPUs. Like its competitor, GSX Server doesn’t provide SMP support for the guest OSs and lets you run a maximum of 64 VMs concurrently on one host, depending on the resources the VMs require. GSX Server supports up to 64GB of memory on PAE-enabled Windows systems, and each VM can address up to 3.6GB of memory.

When I wrote this review, GSX Server officially supported only 32-bit hosts. However, the product also provides “experimental support” for 64-bit hosts, which basically means that they work but aren’t recommended for use in a production setting. I expect VMware to announce official support for 64-bit host OSs after Microsoft releases Windows 2003 for 64-bit Extended Systems later this year.

GSX Server has a decided advantage over Virtual Server in the area of supported host and guest OSs. In addition to supporting all Windows OSs, GSX Server supports a variety of Linux systems as hosts, as you can see in Table 1. The product’s client OS support is equally extensive.

If you’ve used VM Workstation or an earlier version of GSX Server, you’ll find managing GSX Server to be a breeze. Virtual Machine Console. Although it provides decidedly less information than Virtual Server’s Administration Website, it’s easier to use and noticeably more responsive.

Setting up new VMs under GSX Server is decidedly easier than using Virtual Server’s piecemeal VM creation process. GSX Server’s New Virtual Machine Wizard provides an easy-to-use interface that steps you through VM, VHD, and network creation. You’ll probably want to install VMware’s VMTools on all your VMs. VMTools provides a higher-performance video driver and enables cutting and pasting text between the VMs and the host.

VMware gives you several options for remotely managing GSX Server. The Windows-based Virtual Machine Console can connect to networked GSX Server systems. A Web-based management interface enables basic VM management functions, such as displaying and controlling VMs. You can also use a set of scripting APIs for Perl and COM, called the vmPerl and vmCOM APIs, respectively.

GSX Server supports two basic types of virtual disks: raw and virtual. Raw disks directly access a local disk partition. Virtual disks appear to the GSX Server host OS as a file. That file, which has an extension of .vmdk, stores the VM’s entire file system. You can dynamically expand virtual disk files, or you can preallocate files when you create them.

GSX Server’s undo disks let you save or discard all the changes in a VM at the end of a session, and virtual disks have a snapshot feature that lets you capture the current state of the virtual disk. GSX Server also supports differencing, but the associated process is manual and isn’t nearly as easy to use as Virtual Server’s differencing disk capability.

You have a choice of three types of virtual networking for GSX Server VMs: host-only, Network Address Translation (NAT), and bridged. Host-only networking restricts you to internal VMs that have no outside connections. The NAT option lets VMs connect to the outside network using the host IP address. GSX Server provides its own built-in DHCP server for host-only and NAT configurations. Bridged networking lets VMs access the outside network. Alternatively, you can choose None to disable the network hardware.

GSX Server lets you set up Microsoft Cluster service using shared SCSI VHDs. You can also transfer to GSX Server any VMs that you’ve created with VMware Workstation. One key advantage GSX Server has over Virtual Server 2005 is full support for USB devices—I could freely transfer data between GSX Server VMs and USB flash drives.

To test performance, I used the Sandra benchmarking software’s combined performance index tests running on a fresh installation of Windows 2003, Enterprise Edition. I tested a variety of system performance factors, including basic display performance, memory access speed, and file-access and networking performance.

For Virtual Server 2005, I performed all tests on the local server that was running Virtual Server, using the Virtual Machine Remote Control Client running in full-screen mode. I configured the VM to use 384MB of RAM and used a fixed SCSI VHD so the test wouldn’t be affected by dynamic expansion. The VHD was also on a different disk spindle than the drive on which the host OS was installed. To determine whether the Virtual Machine Additions made a significant performance difference, I first ran a set of tests without the Virtual Machine Additions installed, then ran another set after installing them.

In all the performance tests, the VMs running under Virtual Server were slower than those running under GSX Server. The CPU arithmetic test shows Virtual Server lagging behind GSX Server by about 20 percent. The multimedia test showed similar results. The other tests were closer, but GSX Server held onto a 17.5 percent advantage in file system performance and a 5 percent edge in network performance. The presence of the Virtual Machine Additions gave a bigger boost to Virtual Server’s file and network access performance than it did to the product’s arithmetic and multimedia performance.

I configured GSX Server’s VM to use 384MB of RAM and a preallocated virtual SCSI hard disk that was located on a separate physical hard disk from the host system’s OS. I ran two sets of tests: the first without VMTools and the second with VMTools. VMs running under GSX Server provide notably better performance than those running under Virtual Server. Considering that GSX Server is in its third release and Virtual Server is in its first release, it wasn’t surprising that GSX Server is faster.

A Clear Choice
Both products are of excellent quality, and neither gave me any significant problem. If you need to run Linux or other guest OSs in a production environment, VMware GSX Server is the clear choice. VMware officially supports most popular Linux distributions. You can find more information about or download a 30-day evaluation version of VMware GSX Server 3.1 at

For those who have a Microsoft-only environment, however, Virtual Server 2005 is the better value. Significantly less costly than GSX Server, Virtual Server offers all the same capabilities for Windows guest OSs, albeit slightly slower performance. For more information about Virtual Server 2005 or to download a 180-day evaluation version, go to