When installing Windows Server 2008 R2 Domain Controllers on Hyper-V R2, events were generated by AD about being unable to disable write caching for the disks where AD files (database, logs, SYSVOL) were stored. No events were logged for the boot disk. The boot disk is presented as IDE to the VM. The other volumes were presented as SCSI disks. The SCSI disks cannot have their write cache disabled by the Operating System.
My recommendation is on Domain Controllers (or any other server role requiring that the write cache is disabled) which are running as virtual machines, hosted on Windows Server 2008 R2 Hyper-V, ONLY use IDE disks, not SCSI disks for critical AD files. Note this only affects the way the disks are presented to the VM, not to the host Operating System.
If the server is a multi-role server (e.g. AD and File Services), the data disks for the second role can be SCSI disks. Check that this other role does not require write caching to be disabled on the data disks.
Synthetic drivers are drivers which bypass the normal driver layering system between user-mode/kernel-mode in both the child and parent partitions. Instead they use the VMBus to talk more directly to the hardware.
This requires that the child OS partition OS has started up enough to be running the VMBus drivers and services. Until this happens, emulated drivers are used. In this way the OS is said to be “enlightened” to the fact that it is virtualised.
Emulated drivers have no idea the hardware has been virtualized and function in the classic way of attempting to talk to the HAL and eventually “ring 0”. This requires either binary re-writes of these data calls (a la ESX) or hardware virtualization (a la Hyper-V) to create a “ring -1”.
There is a performance hit in using emulated drivers compared to their equivalent synthetic counterparts.
When booting a VM, it is not possible to use SCSI disks as those require the OS to be enlightened, which it is not during installation or boot-up.
So, the boot (and system) partition must be presented to the VM as IDE.
All other partitions can be either SCSI or IDE.
IDE is limited to 3 connected disks (1 port is retained for the CD-ROM, which is required for updating the integration components).
SCSI can have 64 connected disks per controller and 4 controllers per VM, giving a total of 256 SCSI disks per VM.
SCSI also supports hot-add/removal of disks, which IDE disks do not.
Once the OS in the child partition (the VM) has started, there is no perceptible difference between IDE and SCSI for Windows 7/Windows Server 2008 R2 guests.
The results of tests of this are located here:
SCSI disks presented to a VM do NOT support disabling the write cache.
Some roles or applications may require that the disk write cache is disabled. An example of this is Active Directory. When installed on a Windows Server 2008 R2, AD will attempt to tell the OS to disable the write cache of disks holding critical data related to AD:
A warning event will be generated in the “Directory Services” log (ID 1539) for each component described above.
As an example: if AD database and SYSVOL are on the same SCSI disk (D:) and AD logs are in another SCSI disk (E:), 3 events will be generated. D: will have 2 events generated, E: will have 1 event. If the logs are on C:, which is bootable and therefore is an IDE disk, only 2 events will be generated in all.
Thanks for the information. I had spent lot of time trying to figure out why I coudn't disable write caching on my DC VM's SCSI disks. However, this article seems to suggest that you only need to disable write caching if you use IDE disks:
At the bottom of the article it says "To reduce the chance of corruption of Active Directory data, use SCSI controllers or disable write caching on ATA/IDE drives."
Agreed, Charlie. Forster's post is a good elaboration of *Things to Avoid* mentioned in the TechNet article you referenced.
An updated link to the TechNet article:
Guys, this post is now 5 years old. In Hyper-V on Windows Server 2012 R2 we have Generation 2 VMs where booting from SCSI is the norm (along with loads of other cool things, like UEFI booting, which allows for Secure Boot).