Ok. This is what I've learned so far about device access in Hyper-V.
For device access in Hyper-V, there are two underlying methods:- Emulated and VSP/VSC
devices.
Emulated devices are just like the devices you have seen or used in Virtual Server
2005 R2. Whenever the virtual machine or VM attempts to access I/O, the hypervisor
traps that request and the I/O gets emulated in the parent partition. This approach
is highly compatible across most of the OS, but it has its own overhead and slow.
To overcome the above mentioned I/O performance issues, VSP/VSC devices have been
developed in Windows Server 2008 Hyper-V. The hidden caveat is, these are supported
only on specific OS. Of course, Windows 2003 and above is supported. This approach
requires VSC drivers in the guest OS which looks like normal drivers in windows. With
VSC drivers, I/O is not trapped by the hypervisor as it does in emulated one - rather
the VSC drivers directly communicates with VSP's over VMBUS and operates much faster
than emulated devices.
Ok, now we know the two underlying methods available for device access. Let's take
a look at the type of disk contoller Hyper-V provides for storage. The excerpt below
has shamelessly been copied from here.
There are two types of disk controllers that Hyper-V supports: SCSI and IDE.
There are two IDE controllers and four SCSI controllers available.
Each IDE controller can have two devices. You can't boot from a SCSI controller.
This means an IDE disk will be required. The boot disk will be IDE controller
0 Device 0. If you want a CDROM it will consume an IDE device slot.
EACH SCSI controller can support up to 255 devices.
Both SCSI and IDE can support pass-through, Fixed, Dynamic, Sparse, and Delta drives
(see http://blogs.msdn.com/tvoellm/archive/2007/10/13/what-windows-server-virtualization-aka-viridian-storage-is-best-for-you.aspx).
The difference lies in how the controllers are actually implemented. The IDE
controller is emulated where as the SCSI controller is synthetic. So what does
this mean?
The IDE controller implements a well-known IDE controller and this means there is
extra processing before the I/O is sent to the disk. This processing occurs
in vmwp.exe (a user mode process that exists for each started VM. More on this
in a later post). Once the IDE emulation is complete the I/O is sent into the
Root Partition’s I/O Stack. I/O completion requires a trip back to vmwp.exe.
The SCSI controller is not emulated. The SCSI controller uses VMBUS (Virtual
Machine BUS. More on this in a later post). The I/O's pass from the Child
(aka Guest) Partition to the root over VMBUS and enter the I/O stack. You can
already see one less process/machine context switch is required because vmwp.exe does
not get invoked. Once and I/O completes its completion is sent over VMBUS.
There is a lot more to how both the IDE and SCSI controllers work however the descriptions
below should help you to understand why SCSI controllers are the right choice for
the best performance.
One of the main reasons you can't boot off of SCSI device is because it is implemented
as a synthetic device in Hyper-V and the VMBUS is not available during the boot. Rest
of the devices such as CD, IDE, Legacy Network Adapter and Floppy is supported though.
Note: Since Hyper-V is not RTM'ed all numbers are subject to change as are the behaviors.
