I hear a lot of comments about the fact that Hyper-V can expose SCSI disks (either directly attached SCSI disks or LUNs on SAN) to child partitions (also known as guests) as IDE disks.

Before you go telling little Virginia that, “Yes, there is a SAN”, you might want to consider how abstracting that fact is actually a perfectly fine way to configure your virtual machines.

First of all, virtualization is a lot about shielding the child partition from having to understand certains details of the real hardware. This is what makes virtual machines so easy to move between hosts.

Second, even on real hardware, the native BIOS does not really know how to interact with every SCSI disk or SAN. For instance, the way a server typically boots from those disks is through Int 13h extensions put in place by in the BIOS in the HBA, SCSI controller or RAID controller. Those BIOS extensions, which fire before the OS loads, will hook that interrupt and let the OS known enough about the disk to continue going until there’s a good chance to load a driver that understands more about the system. My point here is that, even on a non-virtualized system, there’s a lot of abstraction already going on anyway.

Also keep in mind that, if the guest operating system has the Hyper-V integration components installed, the performance of that Virtual IDE disk will be just as good as that of Virtual SCSI disks. At some point during the OS loading process, we switch from treating the disk as a legacy IDE disk to using the new VSC/VSP model which delivers the improved performance. And this happens automatically, just like holiday magic :-)

While you can argue in favor of exposing more of the real hardware details to child partitions, consider that life as a virtual machine is much simpler if you just believe that those IDE disks just magically appear under the Device Manager tree.

For details about the many ways to expose storage to Hyper-V, check http://blogs.technet.com/josebda/archive/2008/02/14/storage-options-for-windows-server-2008-s-hyper-v.aspx
For the background on that Virginia reference, check http://www.newseum.org/yesvirginia/