Inside Microsoft's Hyper-V Windows 2008 virtualization architecture (formerly Viridian)

Anil Desai describes the technical architecture of Microsoft's upcoming Hyper-V (formerly Viridian) and explains what it means for IT organizations.

Advances in virtualization are commonplace, and it's generally worthwhile to find out what's coming out in the

not-too-distant future. Microsoft's upcoming virtualization product Hyper-V -- formerly known as Viridian and Windows Server Virtualization (WSv) – offers a completely new virtualization architecture, and will be made available as a component of the Windows Server 2008 platform.

While the final production release of Hyper-V is still many months away, preview versions of the technology are available. In this article, I'll start out by describing the technical architecture of Hyper-V and what it means to IT organizations. I won't delve into the recently announced Microsoft Hyper-V Server, the standalone hypervisor-based server virtualization product, as it's not available for review.

Hyper-V hypervisor architecture
I'll begin by explaining how Hyper-V works, rather than diving into a lesson on other virtualization architecture approaches. (For more information on that topic, see the links in the sidebar.)

Choosing server virtualization architectures

Virtualization University 201: Architecture and hardware

Choosing a virtualization approach

In the Microsoft Hyper-V model, a hypervisor layer runs directly atop the physical server hardware. All of the virtual partitions communicate with hardware through the hypervisor, which is a very small and efficient set of code for coordinating these calls.

Figure 1 provides an overview of the architecture.

Figure 1: An overview of the Microsoft Hyper-V Architecture

Each partition represents a virtual machine. The parent partition, which must be running Windows Server 2008, includes the virtualization stack. This stack includes management tools and automation components such as interfaces for Windows Management Instrumentation (WMI). Each child partition can host its own guest operating system (OS). Note that all of the operating systems -- including what might be considered the host OS -- run within partitions.

So far, this probably seems fairly straightforward. However, there are some important architectural departures from current virtualization approaches.

All aboard the VMBus!
Hyper-V includes a minimal microkernel architecture which allows multiple partitions to access the same physical hardware resources. Keeping the hypervisor small helps decrease the security attack surface and helps keep things efficient. Child partitions require the ability to communicate with the parent partition for management purposes. This is done through the use of a logical point-to-point VMBus. Worker processes service administrative operations and requests -- such as starting or monitoring a VM -- from each of the child partitions. The VMBus uses shared memory to securely communicate with VMs on the same host server.

Driver differences
A particularly annoying part of dealing with virtual machines is the issue of hardware drivers. In most implementations, you're limited to the virtual hardware layer that is exposed by your virtualization platform. For compatibility reasons, most virtualization solutions emulate a hardware environment that would have been considered smokin' hot in the mid-1990s, but is the equivalent of a TRS-80 when compared to modern servers. That means that you have two dependencies: (1) the physical hardware must be supported by the virtual emulation layer, and (2) the guest OS must have drivers for the emulated hardware. Often, you'll have the necessary drivers to support the physical hardware, but not the virtualized one.

The primary difference between the Hyper-V approach and that of other hypervisor-based products such as VMware's ESX Server platform is in how drivers work. With Hyper-V, drivers are installed within the guest OS, not within the hypervisor layer. This allows vendors and administrators to use drivers that were designed for the server's physical hardware, rather than the virtualized hardware.

Enlightenments: Guest operating system types
Currently, most potential guest operating systems are unaware of virtualization. They think that they're running directly on server hardware, and therefore require the use of hardware emulation provided by the hypervisor. Each partition that supports a non-hypervisor-aware OS (operating system) uses Hyper-V's emulation layer. This applies to legacy operating systems.

In order to take full advantage of the Hyper-V architecture, guest OSes can use what Microsoft is currently calling "enlightenments". An enlightened guest OS is designed with virtualization in mind and can communicate efficiently with the hypervisor. Enlightened guests run their own drivers that can communicate with the server's physical hardware. For example, a disk-related call can pass directly through to the underlying direct-attached storage array using a SCSI connection. IHVs and OEMs can create their own drivers for these operating systems.

So which OSes can be considered enlightened? While official details haven't been provided, Windows Server 2008 certainly qualifies. Windows Server 2003 and Windows Vista might also be enlightened with updates. Microsoft has also partnered with Citrix XenServer (formerly XenSource) to make the new Hyper-V driver approach available for Linux-based distributions. Over time, more OSes will support these enlightenments, leading to improved performance, security, and compatibility.

More Hyper-V tips to come
This article provided a brief introduction and overview of Hyper-V and how it works. If some of the information is a little confusing, rest assured that it will become clearer as we look at more details. Keep in mind that, at the time of this writing, some of the terminology is likely to change prior to the general availability of Hyper-V. I'll be covering details related to system requirements, instructions for testing early versions of Hyper-V, and new features in Windows Server 2008's virtualization technology in future tips. Stay tuned!

Anil Desai is an independent consultant based in Austin, Tex. He specializes in evaluating, implementing and managing solutions based on Microsoft technologies. He has worked extensively with Microsoft's Server products and the .NET development platform and has managed datacenter environments that support thousands of virtual machines. Anil is an MCSE, MCSD, MCDBA and a Microsoft MVP (Windows Server -- Management Infrastructure). He is the author or coauthor of nearly 20 technical books, including several study guides for Microsoft Certifications.

This was first published in November 2007

Dig deeper on Oracle VM and other virtualization technologies



Enjoy the benefits of Pro+ membership, learn more and join.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: