Microsoft Support for MS SQL on NFS datastores

QUESTION: Is MS SQL supported when running in a vSphere environment where the SQL databases/logs are in a VMDK on an NFS datastore?

Short answer: YES!

Note: I have confirmed this with the Principal Program Manager for SAP, SQL & Azure Customer Programs.

Here are some important Microsoft Knowledge Base articles to confirm this statement.

1. Support policy for Microsoft SQL Server products that are running in a hardware virtualization environment

2. Support policy for Microsoft software that runs on non-Microsoft hardware virtualization software

It is important to note, no where in the above support policies is storage protocol even mentioned. To me this is a very smart move by the SQL team as the underlying storage protocol is abstracted from the VM, making it irrelevant.

The key requirements are:

a) The platform must be SVVP (Server Virtualization Validation Program) certified

VMware is SVVP certified, as is shown by on the SVVP Website.

b) The SQL Server product must be a supported version under its current Microsoft Support Lifecycle policy

For more information about Microsoft Support Lifecycle policies, visit the following Microsoft Support website: http://support.microsoft.com/?pr=lifecycle

c) Virtualization support per SQL features based on SQL Edition

This can be verified here under “Virtualization Support” and the below table is from this KB showing what is supported based on SQL edition.

virtusupportsql

Now in saying SQL is supported when running in a VMDK on NFS datastores, there are some limitations as discussed in SQL AlwaysOn Availability Group support in VMDKs on NFS Datastores.

In summary, old style SQL clustering requiring Shared disks which is not supported.

However SQL Always on Availability Groups (AAG) and SQL Mirroring are supported, which are the two configurations you should be considering these days.

I hope this helps clear up any confusion.

Now for the MS Exchange team to follow the lead of the SQL team!

See Virtualizing Exchange on vSphere with NFS backed storage for more details.

SQL AlwaysOn Availability Group support in VMDKs on NFS Datastores

Recently I had a customer contact me about doing SQL Always-On Availability Groups on Nutanix and they were wondering if it was supported due to the fact Nutanix recommend and run by default NFS datastores.

The customer did the right thing and investigated and came across the following VMware KB:

Microsoft Clustering on VMware vSphere: Guidelines for supported configurations (1037959)

The KB has the following table and the relevant section to MS SQL AAGs is highlighted.

SQLsupportnfs

As you can see the table indicates (incorrectly I might add) that SQL Always On Availability Groups are not supported on NFS when in fact the storage protocol is not relevant to non shared disk deployments.

The article goes onto provide further details about the supported clustering and vSphere versions as shown below with no further (obvious) mention of storage protocols.

pix1

However down the bottom of the article it states (as per the below screenshot):

3. In-Guest clustering solutions that do not use a shared-disk configuration, such as SQL Mirroring, SQL Server Always On Availability Group (Non-shared disk), and Exchange Database Availability Group (DAG), do not require explicit support statements from VMware.

pix2

As a result, SQL Always-On Availability Group non shared disk deployments are supported by VMware when deployed in VMDKs on NFS datastores (as are Exchange DAG deployments).

To ensure there is no further confusion, Michael Webster and I are currently working with VMware to have the KB updated so it is no longer confusing to customers with NFS storage.

For those of you wanting to learn more about Virtualizing SQL Server with vSphere, checkout my friend and colleague Michael Webster (VCDX#66) VMware Press book below.

virtualizing-sql-server-cover-small (1)

vMotion issues when using NFS storage with vSphere 5.5 Update 2

When vMotioning a VM (specifically the .vswp file) residing on an NFS datastore you may see the following error.

vMotion fails with the error: remote host IP_Address failed with status Busy

This issue originally occurred in vSphere 4.1 but appears to have reappeared in vSphere 5.5 Update 2.

Luckily there is a workaround for now, until VMware can investigate and resolve the problem.

The workaround is to modify the advanced setting “Migrate.VMotionResolveSwapType” from the default of 1, to 0 on both the source and destination hosts. If you want to solve this for your entire cluster, then every host needs to be modified.

To modify the setting:
  1. Launch the vSphere Client and log in to your vCenter Server.
  2. Select the source ESX host and then click the Configuration tab.
  3. Click Software > Advanced Settings > Migrate.
  4. Under the Migrate options, locate the line containing Migrate.VMotionResolveSwapType. By default, it is set to 1.
  5. Change the value to 0.
  6. Click OK.
  7. Repeat Steps 2 to 6 for all hosts in the cluster.

The official VMware KB is below.

vMotion fails with the error: remote host IP_Address failed with status Busy(1031636)