To get a virtual machine (VM) to work properly, it's critical to install the Hyper-V integration components. These integration components install agents into a VM that enable a host to successfully back up a VM, recognize when it has gone down, copy and paste data into and out of a VM, and synchronize its clock to the host. These components are important to processing a VM's workload: In effect, their installation reconfigures an operating system to make it "aware" that it has been virtualized, resulting in an "enlightened" OS.
Enlightenment is not only important for a virtual machine to begin working with the hypervisor; it also dramatically changes the driver model for certain key devices. Hyper-V has two classes of device drivers. The first class includes "emulated" drivers. With Hyper-V, emulated device drivers are much like an old pickup truck. They're not fast, they're not pretty, and they're exceptionally common, but they pretty much run everywhere you need them to. Synthetic drivers are more like a sleek race car and are designed to improve VM performance.
Emulated vs. synthetic device drivers
Emulated device drivers operate just as they're named: They emulate a particular kind of device and are used as a stopgap measure until "synthetic" drivers, which are discussed below, can be installed to the operating system. This emulation ensures that a hypervisor can successfully support a VM's OS during its initial build, but a hypervisor will also run dramatically slower because of the need to "translate" resource calls between the emulated driver and the real device on the server. In short, with Hyper-V, you never want to run virtual machines with emulated device drivers. These drivers are present primarily so that a VM can successfully complete its initial OS build and present a shell for the installation of the integration components.
After completing an initial build of a VM's operating system, one of the first tasks is to in...
To continue reading for free, register below or login
To read more you must become a member of SearchServerVirtualization.com
stall the integration components. Completing this step converts emulated drivers into the dramatically more powerful synthetic ones. As mentioned, synthetic drivers are different from emulated drivers because of their awareness of the operating system. With this new awareness, the operating system can change its driver mode from one of strict and slow emulation to what I call a "handshaking" process with the real driver or a desktop shortcut.
A computer's use of a "real" driver will always be faster than any form of emulation will be. The process of translating an emulated device's request into something the real device can understand always adds performance overhead. On the other hand, when operating with a real driver, all requests are submitted without the need for translation. It's the difference between ordering a cheeseburger from your favorite fast-food joint and sitting down for French food and having to translate what's in the escalope de veau perigourdine.* Ordering a cheeseburger requires little brain power. Getting the Escalope to your table likely requires extra effort.
(*Note: With all due respect to the French, the author loves the veal scaloppini and would like another glass of the Bordeaux, please.)
In Hyper-V, installation of integration components creates an important pairing between each virtual machine and the primary partition. That pairing includes a virtualization service provider (VSP) in the primary partition whose job is to interact with virtualization service clients (VSC) in each virtual machine. A VSP/VSC pair exists for the display, network, human interface and storage needs of each virtual machine. Each VSP/VSC pair's channel operates over a common VMBus, which is the communication path among all virtual machines and their parent partitions.
In layman's terms, converting to synthetic drivers will change each virtual machine's drivers to operate much like a desktop shortcut. When a virtual machine requires attention from a device, its request gets redirected across the VMBus to what could be considered the "real" device driver in the primary partition. The net gain is twofold. First, no emulation reduces overhead for virtualization processing. Thus, synthetic devices should create faster VM performance. Second, by using this shortcut methodology, any device driver that works in Windows Server 2008 will automatically work in every enlightened virtual machine.
By looking in Microsoft Device Manager, you can always tell whether you're using the more efficient synthetic drivers in your Hyper-V virtual machines. Look at your display or network adapter drivers. If you see "VMBus" in its name, you know that it is using the synthetic driver approach. If not, install the integration components for best performance.
[IMAGE]About the expert
[IMAGE]
Greg Shields is an independent author, instructor, Microsoft MVP and IT consultant based in Denver. He is a co-founder of Concentrated Technology LLC and has nearly 15 years of experience in IT architecture and enterprise administration. Shields specializes in Microsoft administration, systems management and monitoring, and virtualization. He is the author of several books including Windows Server 2008: What's New/What's Changed, available from Sapien Press.
