Technical overview of Microsoft Virtual Server 2005

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last month, I wrote a post in which I commented on the improved TechNet evenings hosted by Microsoft in the UK. A couple of nights back I attended another one and this time the topic was a technical overview of Microsoft Virtual Server 2005, presented by Thomas Lee from QA Consulting.

Enthusiastic and inspirational, Thomas gave an excellent introduction to Microsoft’s latest virtualisation product, built on the Connectix product which they purchased in February 2003.

At the TechNet event, it was demonstrated on a laptop – definitely not the target environment and at times, the presenter was at pains to point out that this is a v1.0 product, but it seems to me that Microsoft have had some pretty good v1.0 products recently (e.g. Microsoft Office OneNote 2003).

Virtual Server is Microsoft’s attempt to grab some of the virtualisation market, which is intended to address some configuration and architecture challenges:

Server sprawl: Microsoft infrastructure practice tends to lean towards a “one server, one application” mentality; and branch offices often need multiple servers (e.g. to facilitate local e-mail, SQL-based applications and infrastructure roles).
Test environments are a rare luxury for many organisations: virtualisation allows the segmentation of test and production servers, contained on a minimal number of physical computers.
Supporting legacy line of business applications on aging hardware: consolidation of NT 4.0-based applications from out-of-support servers into a virtual environment hosted on modern hardware.

Key virtualisation advantages include:

Rapid deployment of servers (e.g. copy a sysprepped image of a pre-configured servers).
Consolidation of “one application” servers onto a single physical server, resulting in lower hardware maintenance costs and improved support (e.g. in a branch office scenario).
Ability to restore a server to a previously known state in seconds (e.g. in a test/development environment).

Microsoft Virtual Server is a multi-threaded application, optimised for server performance. It includes a web console for remote management as well as a COM API for scripted virtual machine management and although there is a common, compatible underlying technology, it has a different focus to Microsoft Virtual PC, which has a GUI optimised for desktop PC performance.

Available in standard (up to 4 CPUs) and enterprise (up to 32 CPUs) editions, the product can run on Windows Server 2003 Standard, Enterprise or Datacenter Edition as a host operating system (I’m told it will also run on Windows XP, but not so well).

Architecturally, Virtual Server consists of:

Guest operating system and applications.
Virtual hardware.
Virtualisation service.
Windows Server 2003 host operating system.
x86/ia64 server hardware.

While tests indicate good scalability up to the maximum of 32 CPUs and 64Gb RAM, and Virtual Server is able to use teamed NICs and HBAs to increase available bandwidth and avoid bottlenecks, Microsoft did admit that there is a v1.0 “sweet spot” where the application is optimised for less than 8 CPUs (that will be 4 then!) and 32Gb of RAM.

The virtual hardware platform emulates one which is fully supported for NT 4.0 (i.e. is suitable for 70-80% of systems, but not if special hardware is required, e.g. high-end graphics or dedicated serial cards).

Emulated industry standard components include an Intel 440BX motherboard, Intel 21141 NIC and S3 Trio 64 Gfx video card but there is no support for additional drivers, so if the host has (for example) a wireless optical mouse, it just shows up in the virtual machine as a standard IBM PS/2 mouse. It is also optimised for Windows and so although Linux can run as a guest, mouse support is not so good (e.g. when the mouse moves outside the virtual machine screen area, control doesn’t automatically pass back to the host). There are however, some important points to note about the hardware emulation:

RAM is not virtualised – i.e. Virtual Server will not over commit in the way that VMware can by running 3 256Mb virtual machines on a single 512Mb host.
Even though Virtual Server can run on multi-processor computers, it will only expose a single CPU to the guest operating system; however, because each virtual machine runs in its own thread, the host operating system will try and maintain CPU affinity but there is no control over which virtual machines run on which processors. Some may see this as a limitation, but looking at it another way, if an application needs a multiple-processor server, it is probably not really a candidate for virtualisation.
Additional virtual NICs can be used to generate a virtual network which is totally isolated from the physical LAN.

Of course, virtualisation will introduce bottlenecks, but this can be mitigated by comparing performance with the legacy hardware and specifying the host accordingly. Additionally, it is unlikely that all guest applications will peak at the same time. It should be noted that the host operating system file and print data throughput should be maximised for network applications – not for file sharing.

The guest operating system may be Windows NT, 2000, XP, 2003 or even Linux (at the TechNet event, Thomas Lee showed the product running SUSE Linux) and the Virtual Server Web Console allows guests to run in a browser at up to 800×600 resolution (IE only – apparently Firefox does not handle the ActiveX components well). It uses the VMRC protocol which provides access to the virtual BIOS, is operating system independent and is a service hosted by Virtual Server which may also be encrypted using SSL . The standard Microsoft RDP client can also be used to connect to virtual machines (even in full screen mode) – and can be run at the same time as the Web Console; however this option does not provide access to the virtual BIOS. Special key combinations such as Ctrl+Alt+Delete are (by default) provided using Alt Gr+Delete.

Virtual machine configuration (.VMC) files contain all configuration metadata for the virtual machines in XML format. There are combined with virtual hard disk (.VHD) and virtual network configuration files both of which can be copied to another host server for redeployment). CD image files (.ISO) and floppy drive images can also be mounted as drives (only one virtual machine at a time can access physical drives). There is no facility to handle USB disks – they will appear as physical disks to the guest operating system.

Interestingly, as long as the host is not running at a high CPU utilisation (in which case compression would add to the load), there appears to be very little performance degradation in compressing the .VHD files, but a 25% reduction in size can be achieved.

Each virtual machine can have a number of states: turn on; pause; save state (hibernate); turn off; reset; restore from saved state; and discard saved state.

Installing the operating system on a virtual machine does take longer than for a physical computer, but once a sysprepped image of a pre-configured server is created, it can be copied and deployed in minutes (although the size of the .VHD files could increase time significantly). Like physical disks, backups are still necessary to prevent corruptions.

Virtual Server also supports 2-node clusters using a fixed .VHD file. The limitation is that dynamic disks are not supported and both virtual machines must reside on the same server.

Migration Wizards are provided for migrating existing virtual machines and physical computers to Microsoft Virtual Server 2005. Alternatively a manual migration can be used as follows:

Build the virtual machine and load the operating system.
Use virtual networks to isolate servers.
When ready, move the virtual machine to the production network and update DNS/WINS.
Power off the physical computer and the virtual machine can pick up where it left off.

For monitoring status and resource allocation, a COM API is provided with 28 classes and 363 calls. Indeed the Web Console is a reference implementation of this technology, which supports all COM-capable languages for scripting purposes. The use of XML configuration files means that the descriptors are extensible and management solutions (e.g. Microsoft Operations Manager) can leverage or enrich the metadata.

CPU resource allocation uses a relative weight model – i.e. judging how important a particular virtual machine is (based on usage). Virtual Server allocates CPU time, but minimum and maximum thresholds may be set and the virtual machine status may be analysed and tuned to avoid bottlenecks in the system. Physical hardware such as level 2 cache is shared between virtual machines (managed by Virtual Server), so like any memory, more is good, but the presenter’s general feeling was that it may be expensive in terms of a price/performance ratio.

My only prior experience with virtualisation is with VMware (now owned by EMC) and the Connectix Virtual PC product. What I have seen of Virtual PC suggests that it can be a little “flaky” (although I haven’t tried the Microsoft version) and personally, I prefer VMware Workstation for its stability (I have no experience with the VMware server products) but Microsoft Virtual Server 2005 looks impressive and I’ll be trying it out over the next few weeks.