Hyper-V Integration Services Explained, Part 1

The Hyper-V Integration Services, also known as Integration Components and sometimes even Integration Service Components. You know you need them… err, wait, you did know that, right? One of the most critical components to the success of your Hyper-V installation are the Hyper-V Integration Services, and a lot of people know hardly anything about them. Let’s take a closer look.

What They Are

The Hyper-V Integration Services are mostly just that: services. They run inside a virtual machine, providing, well, um, services. As much as I hate to use a word in its definition, sometimes it just doesn’t get clearer. Anyway, some of those services are of the variety that goes into the regular Services list, and some of them are drivers.

Collectively, these services are sometimes called “enlightenments”. This fancy word refers to the concept of making the virtual machine aware of its environment. An “unenlightened” virtual machine doesn’t “know” that it’s virtualized. When the “enlightenments” are installed, it becomes “aware” of it’s situation, hence “enlightened”. OK, the anthropomorphization is a little overboard, but the basic idea is mostly correct. To really understand what this means, you need to first understand what an emulated device is.

Emulation

Consider a hardware device, any hardware device. Let’s say… a network card. What if you wanted to make a computer think it had one of those when it really didn’t, and the act had to be so convincing that the computer could use the non-existent network card to communicate on a network? How would you solve that problem? Emulation is the oldest and most common way.

An emulated device is a software construct that mimics a hardware component. Basically, you design a program that does everything a real network card would do. If a real network card is sent a particular code that means “transmit” with some more stuff that represents transmitted data and it carries out a particular function and sends a response, then that is exactly what your software construct must do. It’s a pretty straightforward concept. Unfortunately, emulation is, by nature, slow. Real hardware is really only limited by how fast it can move electrons. An emulated version of it is limited by how fast the software construct can operate, which is governed by a whole lot more factors. All else being equal, an emulated device will never be as fast as the real thing. Another, and usually much larger, limiting factor is that in a computer, communications with hardware devices are handled through the CPU in a few particular ways. These methods are specifically intended for hardware, not software. So, for your emulated device to behave like a piece of hardware, it has to specifically do things that the CPU believes are reserved for hardware components. The details of this can get pretty deep and I’ll spare you the nitty gritty, but rest assured that it effectively means that emulated devices are slow. So, without Integration Services installed inside your virtual machine, it’s going to run slowly.

Synthetic

In the Hyper-V world, the opposite of “emulated” is “synthetic”. In other hypervisors, similar technologies get different descriptors, but they all basically mean “not emulated”. As far as the virtual machine is concerned, it still has its own perfectly functional device, although it really doesn’t (so, it’s not really all that “enlightened” at all, is it?). However, there is no full-blown artificial construct. When the virtual machine communicates with this “hardware”, the messages are passed to its synthetic driver, which channels them through Hyper-V right to the hardware abstraction layer and then on to the actual hardware with very minimal translation. It’s effectively like talking to a regular hardware driver but with one more layer to go through. As you can imagine, synthetic devices are usually substantially faster than emulated devices. The big synthetic drivers that you’re likely to actually see in action inside a virtual machine are the network drivers and the SCSI drivers.

Synthetic devices require a driver to be loaded, and the order that they load when the guest operating system boots precludes them from making the devices available until the OS has mostly loaded. In plain language, that means that synthetic devices don’t even exist until a fairly late point in the guest’s boot cycle. You can’t load the bootable portion or the page file of a Hyper-V operating system on a virtual SCSI volume and you can’t use PXE with a synthetic network adapter.

There are other synthetic devices made available by the Integration Services, and if you really care, you can find them pretty easily. Those go to work automatically without you needing to do anything beyond installing Integration Services though, so it’s not really important that you know them. The thing you must know is that, without Integration Services installed and functional, your virtual machine will be slow.

Affected Operating Systems

Windows guest operating systems from Windows XP with Service Pack 2 onward and Windows Server operating systems from 2003 with Service Pack 2 onward can load the Integration Services. Windows XP still has some performance issues even after the components are loaded.

There are a few separate iterations of the components available for Linux guests. The earlier versions are available on the Microsoft download site. Recent versions of the Linux kernel include these components, so no separate install is required. Research what’s available for your particular distribution prior to installing anything. The only distribution I ever really tested in any depth was Ubuntu Desktop 12.04 LTS and I had no issues except with video. The performance was acceptable, but resolution choices were limited.

Further reading

• In part two of this series, we’ll look at the more service-like services.
• How To Install Integration Services in Hyper-V
• How To Enable and Disable Integration Services in Hyper-V