For those of you with your mission-critical servers already virtualized on a VMware-based virtual infrastructure, are you using the VMware Paravirtual SCSI driver to boost your I/O performance by an average of 12%? I use it for all of my I/O intensive virtual machines, including SQL Server and Oracle VMs, and you should too!
By default for Windows Server 2008 and above, the default virtual SCSI controller is the LSI Logic SAS disk controller. It’s there for compatibility purposes, and piggybacks the existing driver that is built into the operating system. It works great because it always ‘just works’.
However, compatibility does not necessarily mean fastest, and the LSI SAS driver is a pretty good performer, but VMware developed an alternative that can boost performance for virtual machines with high I/O requirements. It is called the Paravirtual SCSI (PVSCSI) driver, and it is included with the VMware Tools package that should be installed into every VMware-based virtual machine. This driver was designed by VMware to improve the raw performance of every virtual disk connected to it. On average, I experience a 12% throughput performance improvement, lower latency to the underlying storage, and lower CPU associated with storage handling when using this driver.
How can you take advantage of this driver?
It’s easy! Virtual disks are connected to virtual disk controllers. All we have to do is ensure that the VMware Tools are installed (so the driver is present) and then make a few changes to the VM configuration.
First, check out the virtual disk configuration of the VM. This example uses an older Windows Server 2008R2 VM. Almost always, one or more virtual disks are connected to the LSI SAS controller. See how the disk assignments are set to a SCSI ID of 0:0 and 0:1? This is how the old SCSI hardware configuration was emulated with the advenet of virtualization. The first number is the controller number, and the second is the SCSI channel assignment.
Also notice that we only have one SCSI controller present in the VM configuration. Let’s fix this. This example is performed in my lab via the vSphere Web Client on a vSphere 5.5 base system. The vSphere client update procedure on older installations is slightly different but the same concepts apply.
Gracefully shut down a virtual machine. Edit the virtual machine settings. Add a new SCSI controller. The default type is again LSI SAS. Expand the new hardware entry and change it to Paravirtual. Click OK to save the changes.
Edit the settings again. Pick a virtual disk that is not the bootable root volume (I’ll explain more on this in a little bit) and select the virtual disk. In this case we’ll pick the second virtual disk. Change the disk’s SCSI assignment from 0:1 to 1:0. Click OK to save the configuration.
Now, power on the virtual machine. When Windows comes up, it will detect the new hardware and should prompt you to reboot the VM. Go ahead and do so. Once it comes up, check in the Disk Manager to make sure that the disks are online. Occasionally I have seen the disks go offline because of the change to the underlying controllers. A simple set online operation will fix this if it occurs.
Update: the following command can change the Windows disk online/offline process to ensure that these drives stay on.
Set-StorageSetting -NewDiskPolicy OnlineAll
Now, as always, benchmark your storage performance before and after the change to ensure that you actually do receive a performance improvement, because every system is different.
Why Not Boot Volume?
Earlier I mentioned not to use the PVSCSI driver on boot volumes. I do this intentionally. If for whatever reason there is a problem with the VMware Tools and the associated components, the PVSCSI driver could have a challenge starting up. Just once, many years ago, I experienced the scenario where the boot disk depended on the PVSCSI driver to load, but could not load to the VM could not boot. The operating system needed to boot successfully in order to properly re-load the PVSCSI driver, so it was a chicken-and-egg scenario. I have not experienced it in years, but once was enough to scar me. Keep the bootable volume on a driver that is native to the operating system, and you eliminate the remote chance of running into issues with this scenario.
VMware has a great matrix of operating systems and the compatibility settings in their KB located here.
The SCSI queue depth in Windows for these disks is 64. If you need to change the SCSI queue depth in Windows beyond this value, VMware has instructions located here.
Now you can get a noticeable and measurable disk performance boost on your existing VMs with just a couple of reboots! Go forth and improve your mission-critical VM performance with this little update – for free!