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 not 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.
[[ Since Hyper-V is not RTM’ed all numbers are subject to change as are the behaviors. ]]