Types of Controllers
In Chapter 2, I told you about two types of storage controllers available in a generation
1 virtual machine, IDE and SCSI, while a generation 2 virtual machine supports only
the SCSI controller. In a generation 1 virtual machine, the operating system VHDX
must be connected to the IDE controller because the SCSI controller does not support
bootable devices. In a generation 2 virtual machine, though, the SCSI controller does
support bootable devices, allowing the operating system VHDX file to be connected to
the SCSI controller.
A generation 1 virtual machine has two IDE controllers, with each controller
supporting up to two virtual devices, which could be VHD/VHDX files or virtual DVD
drives. Both generation 1 and generation 2 virtual machines support up to four SCSI
controllers, with each SCSI controller supporting up to 64 virtual hard disks. Even
though the performance of the IDE controller and SCSI controller are equivalent, once
the integration services are loaded, the fact that so many more disks are supported on
the SCSI controller means that in most environments, the IDE controller is used
solely for the operating system storage while all data disks connect to the SCSI
controller.
There is one additional difference, or was, between the IDE and SCSI virtual
controllers that is important to be aware of and that also makes the SCSI controller a
better choice for any kind of database: caching behavior, or more specifically, how
write cache is reported. For any kind of database, you typically do not want any write
caching on the device. Write caching is a technology that enables storage to report that
a write has been committed to disk, while it actually is cached in the controller and
will be written in the most optimal way at a later time. The danger with write caching
is that if an unplanned outage occurs, the data in the volatile cache is never written to
the disk and is lost. This is bad for any kind of database, including Active Directory.
With Hyper-V, write caching cannot be disabled on virtual hard disks, because there is
no way to ensure that there is not an always-on write cache on the underlying storage
or that the VHDX may one day be moved to a disk with an always-on write cache using
storage or Live Migration technologies. Additionally, because many VHDX files can
reside on a single physical disk, there is no way to be sure all VHDX files on the
physical disk would want the write cache disabled, and the configuration of write-
cache is a physical disk setting. When the write cache is disabled on a disk that is
using Device Manager and is connected to the virtual SCSI controller, an error is
displayed, as shown in Figure 4.1. This is important, because applications also try to
disable write caching, and the error notifying that the write cache could not be
disabled allows any application that needs to ensure data write integrity to use
alternative methods, specifically Force Unit Access (FUA), to ensure that data is not
cached.