Why Hyper-V cannot boot off of SCSI disks (and why you should not care)

Why Hyper-V cannot boot off of SCSI disks (and why you should not care)

  • Comments 20

Under Hyper-V we have two kinds of disk controller that you can add to a virtual machine – IDE disks and SCSI disks.  A rough list of the differences between these controllers is as follows:

IDE:

  • Works on operating systems without integration services installed / available
  • Can be used to boot a virtual machine

SCSI:

  • Supports hot add / remove of virtual hard disks

The type of disk controller that you use in the virtual machine has nothing to do with the type of disk that you are using in your physical computer.  SCSI VHDs can be stored on IDE disks, and IDE VHDs can be stored on SCSI disks.

Why can’t you boot Hyper-V virtual machines off of SCSI disks?

Well, calling our SCSI controller “SCSI” is somewhat of a misnomer.

When we were working on Virtual Server we heard, loud and clear, that servers had SCSI disks – so virtual servers needed to have virtual SCSI disks.  To this end we invested in the emulation of an Adaptec SCSI controller for Virtual Server.  Unfortunately, this SCSI controller is a very advanced piece of hardware – and as a result was actually slower to emulate than the more simplistic IDE controller that we were already emulating.

In the end we had to extend our emulated Adaptec controller and write custom drivers for our supported operating systems in order to get good performance for SCSI in a virtual machine.

With Hyper-V we dropped the emulation of an Adaptec controller altogether.  Instead we implemented our traditional emulated IDE controller and a new completely virtual, VMBUS based, storage controller - with no traces of emulation present.

It is this virtual storage controller that you are adding to a virtual machine when you choose to add a SCSI controller to a virtual machine.

The problem is that the BIOS that is used by our virtual machine has no knowledge of VMBUS and is only able to boot to emulated devices.  This is why you can boot to an IDE controller and a legacy network adapter – but not to a SCSI controller or network adapter.

Why you should not care about not being able to boot off of SCSI disks in Hyper-V.

When talking to users about needing to boot off of SCSI disks in a virtual machine – there were two reasons that came up.

The first one was that SCSI could support larger virtual hard disks than IDE could.  To address this we made the IDE controller in Hyper-V use 48-bit LBA.  This allows you to attach virtual hard disks that are up to 2TB in size to an IDE controller.

The second reason was performance.  But that too is not an issue.

Let me start by grabbing an architectural diagram I have on file (you can tell that this is an old diagram because it uses our codename – Viridian – which means it was originally drawn before we had been given “Hyper-V” as our name).  Now, the parent partition diagram is not 100% correct for Windows Server 2008 R2 – but the child partition diagram is accurate for both Windows Server 2008 and Windows Server 2008 R2, and that is where I want to focus.

storage

The first thing to notice in the child partition side of things is the “Virtual Storage Minport (VSC)”.  The is essentially the driver that gets loaded when you attach a SCSI controller to a virtual machine.  It connects to VMBUS and allows us to perform Disk I/O without any emulation involved in a very high performance manner.

The next thing to notice is the “Fast Path Filter”.  This is a filter driver that gets installed on all disk objects in the virtual machine – whether they are IDE or SCSI.  It allows us to pass directly to the VMBUS based path for everything except low level disk operations (like partitioning a disk).

What this means is that once the integration services are installed the same code path is used for disk I/O whether you use an IDE disk or a SCSI disk.  There are two limitations that remain for IDE disks:

  • Disk commands to IDE disks on the same controller are serialized by the guest operating system (note that you can only have two IDE disks on a single controller)
  • The IDE disk is limited to I/O block sizes of 512kb or less – while the SCSI controller can go up to block sizes of 8mb

However I have yet to see a test where either of these limitations resulted in a noticeable performance difference between IDE and SCSI.

Cheers,
Ben

Leave a Comment
  • Please add 6 and 1 and type the answer here:
  • Post
  • IIRC, on IDE controllers there was a performance penalty if both the master and slave drives were reading/writing at the same time.  Is this not the case on Hyper-V?  Or is it preferable to have one disk on each controller rather than having both on the same IDE controller?

  • Q.Q I want to install AD on the default hard drive on a Hyper  V Machine. WHY MUST I GET WRITE ERRORS!

  • Hi Ben.

    I now this post is old. However I do care about booting from SCSI disks, as we have several Linux virtual machines running within VMware ESX hosts that we are not able to migrate into Hyper-V 2012 R2. Even we have converted the disks and re-created the machines as Gen2 into Hyper-V, the won't boot at all.

    When using VMware SCSI disks with a non-Microsoft OS, it seems there's no compatibility yet that allows Hyper-V to go smooth.

  • Not run multiple virtual machine so check BIOS setting and disable IDE controller

    Problem solve.

    Erro to promote me is IDE controller id used in unother process

  • I get that there may be technical reasons for this and that. But really? Why on earth can't you boot from a SCSI disk on Gen 1? You know what? Don't answer that, unless you can say we're working on it.

    Why?

    Because if you want to take market share from VMware and make it easier for businesses to move to Hyper V, you have to give beneficial reasons to do so.

    VMware can boot machines from their "SCSI Controllers" and therefore, when you need to extend a drive for a running virtual machine that has Server 2008 R2 or better, you can cheerfully grow the disk out and then extend the volume without fear of having to take down a running VM and potentially causing a brief outage to your business.

    If you choose to migrate (and I am talking about a V2V) from VMware using SCVMM, your VM loses the ability to have the drives resized when needed. This is horrible on MS' Part and few admins are willing to have to rebuild their environment in a new Virtualization space to accommodate the lost functionality. It would totally defeat the purpose of virtualizing and making things more dynamic and robust.

    I do love Hyper V, but this is a pretty major oversight and misstep on MS part. I'm sure I'm not the only one saying "Please remedy this!!!!"

Page 2 of 2 (20 items) 12