NMP Multipathing rules for the FlashArray are now default

Round Robin and IO Operations Limit of 1 is now default in ESXi for the Pure Storage FlashArray! This means that you no longer need to create a custom SATP rule when provisioning a new host or adding your first FlashArray into an existing environment.

So this change is actually in two branches of ESXi:

1. ESXi 6.0 Express Patch 5 (build 5572656) and later (Release notes)
2. ESXi 6.5 Update 1 (build 5969303)and later (Release notes)

In their release notes you will see the following note:

“For a Pure Storage FlashArray device you have to add manually the SATP rule to set the SATP, PSP and IOPs. The issue is resolved in this release and a new SATP rule is added to ESXi to set SATP to VMW_SATP_ALUA, PSP to VMW_PSP_RR, and IOPs to 1 for all Pure Storage FlashArray models.”

What this is saying that all Pure Storage FlashArray devices will be configured by default to use Round Robin and an IO Operations Limit of 1. For a quick refresher the IO Operations Limit is how often, for a given device, ESXi switches logical paths. We recommend setting this to 1 due to primarily path failover time is improved by quite a bit when this is set low.

So once you are on these release you no longer need to worry about this any more. Yay!

So what does the upgrade look like, and what if you have an existing rule? Well let’s first look at it for a fresh upgrade with no manually created rule.

Upgrade with no Pre-Existing SATP Rule

 

So in this ESXi 6.5.0 host I have no custom SATP rule for the FlashArray as seen by this command:

So let’s upgrade! I have my update on one of my VMFS volumes, but you can do it directly from VMware’s website too of course.

Now reboot.

When it comes back up, a new rule will exist:

Upgrade with a Pre-Existing SATP Rule

This is probably the more likely case, where you have already created a custom rule for the FlashArray either via SSH with this command:

Or with PowerCLI with one of my scripts or your own.

In this case, in a pre-6.5.1 ESXi (or pre-6.0 P5) you would see something like this:

Now let’s run the upgrade on this host.

When it comes up we can run the command again to see what rules are there:

You can see two rules now, my original one and the new one. You can tell the difference between the two by looking at the “Rule Group” column. The one you created in the past will be of type “user” and the new one is of type “system”.

At this point you can delete the SATP rule that you created. This blog post talks about how to remove a SATP rule. I wrote a PowerCLI script here that does the following here though:

1. Finds any host with a system rule for the FlashArray.
2. Looks on that host for any user FlashArray rule that is the same as the system one and deletes it.
3. If the FlashArray user rule is different it skips. For more info on conflicting configurations on rules, read on to the next section.

NOTE: You don’t have to delete old rules. This is really more for keeping things clean to look at, and removing old unnecessary configurations.

What about a host with a user rule that differs from the new default? Like let’s say it has an IO Operations Limit of 5 set? How does the upgrade work. Let’s take a look!

Upgrade with a Conflicting Pre-Existing SATP Rule

So in this situation I have a “user” rule that indicates an IO Operation Limit of 5, which conflicts with the new default rule that configures the FlashArray volumes with an IO Operations Limit of 1.

You can see one of my FlashArray devices has a IO Operations Limit of 5 (iops):

So after upgrade who takes precedence if the user rule is not deleted first? So let’s update to 6.5.1 and reboot.

We now have two rules, one is the “system” rule which says IO Operations Limit should be 1 and a “user” rule that says IO Operations Limit should be 5.

So how are the devices configured?

Let’s run the device list command again:

All of my FlashArray devices are still configured as IO Operations Limit is 5:

So what this means is this: “user” rules override system “rules”. So there is no need to be concerned during an upgrade if for some reason you have a conflicting rule. ESXi will apply your custom user rule to all FlashArray storage and it will ignore the system rule.

One less thing to do now for VMware and the FlashArray!