vSphere 6.7 & SRM 8.1

Today VMware has posted the newest release of their flagship vSphere product, 6.7. In addition they have also dropped Site Recovery Manager (SRM) 8.1. A new vSphere release always means lots of new features, and I’d be a fool to try to enumerate them seeing as there is a document for that. I’ll mention a couple, then I’m just going to stick with those directly impacting the VMAX array.

So two things come to mind. First, vSphere 6.7 no longer supports VMFS 3. If it encounters any during install/upgrade, it will convert them automatically to VMFS 5 (remember you can’t upgrade to VMFS 6). Second, from what I can tell the HTML 5 client is almost fully realized. You can still use the vSphere Web Client (why would you?) if you want but even VMware figures you don’t want to so they have this helpful button when you are in the Web Client.

On to the storage ones…

VAAI

VMware has made three significant changes to the VAAI primitives in 6.7, though all interrelated. The first is one that impacts all the primitives, while the other two focus on the specific primitives of Full Copy or XCOPY and Dead Space Reclamation or UNMAP. Let’s start with the general change.

Generic Plugin

The implementation of VAAI on vendor arrays with VMware has always been done through claim rules. VAAI is a plug-in claim rule that says if a device is from a particular vendor, in this case a Dell EMC VMAX device, it should go through the VAAI filter. VMware had vendors create their own custom plugin which they deliver for us in each vSphere release so the customers do not have load it manually. Below the red box contains the VMAX VAAI filter rule, the blue box the VAAI rule, and then in green it shows what plugins are currently in use. As I only have VMAX devices presented, The VMAX one, VMW_VAAIP_SYMM, is the only one listed.

Sometimes vendors do not create one, and they have to deliver the plugin as a file to install. VNX and eNAS do this to enable their VAAI capability (see TechBook for detail).

When the device is claimed by the VAAI filter, it will show in the detail of the command esxcli storage core device list:

Since the inception of VAAI in vSphere 4.1, this is how vendors support it.
Starting with vSphere 6.7, VMware has decided they want to get away from vendor-supplied VAAI plugins and instead have all vendors use the VMware generic plugin VMW_VAAIP_T10 (in reference to the VAAI commands which are SCSI T10 , e.g. UNMAP). Now fortunately vendor plugins are fairly generic so the hope is this plugin acts just like the custom one. And our testing has shown that it does for PowerMax/VMAX. To use existing functionality, the transition to this generic plugin, however, is not mandatory in this release. My screenshots above are from 6.7 so clearly you see our custom plugins are there. I say existing functionality because VMware is delivering new functionality in the plugin specifically for XCOPY.

XCOPY

The new functionality has to do with how large an extent size VMware can send for copying data on the array. By default VMware only sends a maximum of 4 MB but it can be increased to 16 MB. In 6.7, if a customer uses the new plugin, they can configure VMware to send an extent size up to 240 MB (assuming the copy job has an extent that large). Now I can hear people shouting at me, “wait, VMAX can do that already!” Damn straight. VMAX has had this capability since vSphere 6.0 because we asked VMware to build it into the code for us. So this “new” functionality is not new for us. Here is the one difference for us, and it is good news if you are already using this capability. Our custom VAAI plugin allows the customization to 240 MB. We don’t need VMware’s generic plugin. In fact, VMware simply ported over what was in our custom plugin into the generic plugin so other vendors could use it. But, here’s the rub. VMware is moving to this generic plugin and my guess is in the next release it will be mandatory. Therefore my advice is if you aren’t using our plugin’s ability to send 240 MB now, or have servers that have not been configured, then it is best to configure the generic plugin to do it. It will save you time in the future. I’m going to give you the quick explanation for using the generic plugin. Please see my VAAI paper if you want more detail about these custom rules.

First, the existing custom vendor rule must be removed. Because VMware suggests using claim rule number 914, remove both the Filter and VAAI classes. Note that if an attempt is made to add claim rule 914 before 65430 is removed, VMware will error and indicate 914 is a duplicate of 65430. Be careful with copy and paste from the blog because it may remove the double-dashes.
         esxcli storage core claimrule remove –rule 65430 –claimrule-class=Filter
         esxcli storage core claimrule remove –rule 65430 –claimrule-class=VAAI

To prevent failures in adding the next rule in some ESXi versions, reload the claimrule classes:

esxcli storage core claimrule load –claimrule-class=VAAI
esxcli storage core claimrule load –claimrule-class=Filter

Now add the new filter and rule.
         esxcli storage core claimrule add -r 914 -t vendor -V EMC -M SYMMETRIX -P VAAI_FILTER -c Filter
         esxcli storage core claimrule add -r 914 -t vendor -V EMC -M SYMMETRIX -P VMW_VAAIP_T10 -c VAAI -a -s -m 240

Reboot the ESXi host for the changes to take effect. When the host comes back up, you will be able to see that the new rule is loaded (file and runtime). I have this boxed in red. You also will notice that because the old rule 65430 is part of the ESXi code, VMware is still going to list it, but it is not part of the runtime as the new rule is and therefore not used.

One quick caveat about increasing the XCOPY extent size. When using Storage vMotion, the maximum extent size is 64 MB. This is a VMware restriction and has nothing to do with the array.

UNMAP

The second VAAI primitive VMware enhanced is UNMAP. This one is actually similar to the XCOPY changes in a way. As this feature requires some detailed explanation I’m going to create another post to this one so I don’t turn this into a book. You can find it here.

Product/Plugin Interoperability

Here are some things to know about vSphere 6.7 and SRM 8.1 interoperability with Dell EMC products. I should preface this by explaining that for our products that are released multiple times in a calendar year, support for new VMware releases typically follow with the next version of the product. Rarely do we retroactively certify an older release with the new VMware release unless we have a customer request based on a business case.

VMAX Arrays

Our VMAX arrays (VMAX, VMAX3, VMAX All Flash) do support vSphere 6.7. Be sure to check out the ESSM to find out the necessary Enginuity/HYPERMAX OS software needed on your array model.

 

Virtual Storage Integrator (VSI)

VSI requires a new build to support vSphere 6.7. Originally support was to come in version 7.3 but a bug prevented it from working properly. Normally this would not be a cause of concern in an existing environment that is upgraded because VSI would be the thing that would error, not vSphere. Unfortunately something about the vSphere 6.7 Web Client breaks VSI and subsequently can break the upgrade process. I recently did an upgrade of my VCSA which had VSI installed and when the upgrade approached the end of the process, I received an unfriendly error message telling me my plugin was broken. I hit OK and the upgrade appeared to complete normally – and everything worked fine. I checked the Administration/plugin page but VSI was not there; however when I checked the /mob page it was. I manually removed it, but it didn’t seem to cause me a problem. My experience does not seem to be universal though as VSI developers had their upgrades outright fail. I’m going to err on the side of caution, therefore, and recommend you uninstall (deregister from SIS) the VSI plugin before upgrading to 6.7 or upgrade VSI to the latest 7.3 which you can read about in another post.

Dell EMC Enterprise Storage Analytics (ESA)

We just released  a new version of ESA the other day which supports the latest vRealize Operations 6.7. ESA does not have to certify with vSphere versions as vROps handles that so as long as vROps supports it (which it does if you couldn’t tell by the version), we are good.

VMAX Plugin for vRealize Orchestrator

This is a plugin that like ESA relies on the underlying software in which it is installed. The current VMAX Plugin works with vRO 7.2 and 7.3. I have not had a chance to test it with 7.4.

VMware Virtual Volumes (VVols)

Our current VASA Provider 8.4 is not, and will not be certified with vSphere 6.7. I suspect a future version of the VASA Provider will. If you are using VVols, therefore, do not upgrade your environment.

Storage Replication Adapter for SRDF (SRM)

Currently there is no SRDF SRA that supports SRM 8.1. This is one of those products that release multiple times a year so the next version (in conjunction with the PowerMax release) should support it either at GA or shortly thereafter. If you anticipate you need support for SRM 8.1 for an older SRA because you can’t upgrade that component, you will need to file a request with your Dell EMC sales team. No guarantees of course as any request must go through the same process. Sometimes it just isn’t possible to certify an older release.

Documentation

As I’ve mentioned before, I do most of the non-product documentation for VMAX/VMware integration. Major releases like this require significant testing and make it difficult, if not impossible, to get published docs out there in time for GA. I therefore try to get all the important information out on my blog as a minimum while I work on doc updates. If there is something about vSphere 6.7 and VMAX you would like to know, please drop me a comment here and I’ll post about it in the meantime.