Hyper-V Architecture - Virtual Machine

A VM can have two different types of devices: emulated and synthetic. Although synthetic devices are encouraged due to their superior performance, they aren’t available for all operating systems. Emulated devices are present in Hyper-V mainly for backward compatibility with nonsupported operating systems. VMs running certain distributions of Linux have synthetic device support as well. Let’s examine each type of device.


Emulated Devices
Emulated devices in Hyper-V exist primarily for backward compatibility with older operating systems. In an ideal world, all applications would run on the latest version of the operating system they were designed for, but that’s far from reality. Many companies have systems in production that run on older copies of operating systems because one of their applications doesn’t run on anything newer. An older operating system may not be supported under Hyper-V, which means it can’t take advantage of the high-performance I/O. That’s not a total loss, however: If you consolidate those older systems onto a newer Hyper-V host, the advantages of moving to a more up-to-date hardware platform can provide a performance boost.

Emulated devices have another key role. During the installation of the VM, operating systems don’t have support for the synthetic devices that may be installed in the VM. For that reason, you must use emulated devices—otherwise, the operating-system installation can’t function. For Hyper-V, it’s easy to move from emulated to synthetic devices.

The emulated devices presented to a VM are chosen for their high degree of compatibility
across a wide range of operating systems and in-box driver support. The video card is based on an S3 video card, and the network card is an Intel 21140-based Ethernet adapter.

Emulated devices under Hyper-V don’t perform as well as the new synthetic devices. Thanks to part of the work that was done to harden the entire virtualization stack, emulated devices execute in the worker process—specifically, in user mode in the parent partition.

How does I/O happen with emulated devices?

The below are about how emulated storage requests are handled. Emulated networking is handled in a similar fashion. I want to point out a few specific items:

• Context switches are used. A context switch is a switch from executing a particular processor instruction in kernel mode to user mode. When paired with virtualization, a context switch is an “expensive” operation. There’s no money involved, but the CPU cost for such an operation is very high. That time could be spent doing other tasks.

• The path that the data packet traverses is long, especially compared to the synthetic case (which we’ll review next).

• The path illustrated in the figure is repeated hundreds of times for a 10 kilobyte write to disk. Imagine if you’re doing a large SQL transaction that involved writing hundreds of megabytes to disk, or running a popular website being served up from IIS running in the VM. You can see that it won’t scale well.


Synthetic Device Drivers
Synthetic devices provide much higher performance than their emulated counterparts. By taking advantage of VMBus, synthetic devices can execute I/O transactions at a much faster rate. Synthetic devices, such as the Microsoft Virtual Machine Bus Network Adapter, don’t have real-world counterparts. They are purely virtual devices that function only with Hyper-V—loading the drivers on a physical system does nothing. These new synthetic devices rely on VMBus.

Synthetic device drivers are available only for operating systems that are supported by Microsoft. (For reference, a list of supported operating systems for Hyper-V is available at www.microsoft.com/virtualization.) If you’re running an operating system in the VM that isn’t supported by Microsoft, you’ll need to use the emulated devices in the VM. Much like the emulated storage request chart presents a lot of data. Here are a few key differences:

• In the beginning, the data path is similar to the emulated data path. •u However, the synthetic storage device in Hyper-V is a SCSI-based device—so the last driver it hits before getting put on VMBus is the StorPort driver.

• When a packet makes it to the miniport driver, it’s put on VMBus for transport to the Storage VSP in the parent partition. Because VMBus is a kernel-mode driver, no context switches are necessary.

• After the data packet crosses over to the parent partition, the correct destination is determined by the VSP, which routes the packet to the correct device. The destination is a virtual hard disk (VHD) file.


Installing Synthetic Device Drivers
It’s easy to install synthetic device drivers in the VM. After you’ve installed the operating system, select Action -> Insert Integration Services Setup Disk. An installer launches and automatically installs the drivers for you. When you reboot, the VM can take advantage of the new architecture.

A special synthetic driver deals with the boot process: Optimized Note Boot Performance.
Because the synthetic drivers rely on VMBus, you can’t boot off hard drives that are connected to the SCSI controller. All isn’t lost—during the boot process, after the VMBus driver is loaded, all the IDE boot traffic is automatically routed through the same infrastructure that is used for SCSI traffic. This means the boot process and all disk traffic (reads and writes) perform at the same accelerated speed.


Linux Device Drivers
No, that’s not a typo—certain distributions of Linux are supported under Hyper-V. Not only is the operating system supported, but a full set of device drivers also enable synthetic device support under Linux. The drivers include the Hypercall adapter—a thin piece of software that runs in the Linux VM and increases performance by translating certain instructions to a format that Hyper-V can understand.

Source of Information : Sybex Windows Server 2008 Hyper-V Insiders Guide to Microsofts Hypervisor