Updated FlashArray VMware Best Practices PowerCLI Scripts

I wrote a post recently on the updates made to the PowerCLI 6.3 R1 esxcli implementation, so the logical next step was to implement this new behavior into my PowerCLI scripts that use esxcli. I still have a few scripts to update, but my two best practice-related scripts are ready to go. The two scripts are:

  1. Script to check and set best practices. Download here:
  2. Script to just check best practices, and lists issues in a report. Download here.

While I was updating them for esxcli changes, I figured i might as well improve them too, so there are quite a few changes for both. Let’s take a look.

Comments on both scripts

To get these scripts to work, you need to enter in four variables the: vCenter IP or FQDN, username, password and a log folder location. The best practices set script is interactive (add them in as it runs). The checker is still hard-coded variables. This will change soon.

This script will then check and if needed, change, all of the hosts in that vCenter for FlashArray best practices for ESXi. If you want it to only touch a certain cluster or host, change the line (113 in the one script, 115 in the other) which says $hosts= get-vmhost. Add a get-cluster to it, or the host name to narrow down. Otherwise it will just do it to all of the hosts in that vCenter that the supplied credentials can access.

Furthermore, they both NEED PowerCLI 6.3 R1+ to work because of the esxcli changes. You do not need to upgrade your vCenter/ESXi etc to get this to work, just PowerCLI. Otherwise it will fail:


Both scripts will also create the log folder if it does not exist. Almost zero information gets logged to the screen, pretty much everything goes into that log. The only stuff that goes to the screen is generally connection errors, or an error like above.

Furthermore, both have a few “hidden settings”. The I/O Operations Limit value called “$iopsvalue” and the ability to turn host-wide settings checks to off or on “$hostwidesettings”. I do not recommend changing these unless you have a good reason. The Pure Storage FlashArray recommendation for IO Operations Limit is to set it to 1. If for some reason your organization has a different value you can change this from 1 to whatever, this will remove all of the warnings/changes that would occur for it being different than 1. Also the $hostwidesettings (boolean) defaults to $true. Meaning it will check and set the host wide settings we recommend. This check can be totally skipped by changing this to $false. Some customers don’t want to change things like the VAAI XCOPY transfer size for instance because it can interfere with other storage systems performance that might also be present. If this is disabled, only settings that affect FlashArray devices and only FlashArray devices will be looked at/changed.

Okay now for some details on the scripts themselves.


Best Practice Check and Set

This script will CHANGE SETTINGS if found to be incorrect. So please understand it before running. Feel free to ask 🙂

This script checks for best practices and also sets them if they are found to be incorrect or missing. The script focuses on two things host-wide settings and multipathing configuration.

This script only focuses on recommendations that DIFFER from DEFAULT ESXi settings. We have other recommendations but those revolve around keeping things at defaults. This script does not look at those (use to checker script to find issues there).

This script looks at:

  • VAAI XCOPY transfer size and makes sure it is set to 16 MB on each host instead of the default of 4 MB.
  • EnableBlockDelete: If the host is ESXi 6.0 or later it makes sure this is enabled to allow for in-guest end-to-end UNMAP when applicable.


  • SATP rule for Pure Storage FlashArray devices: Checks to see if a default rule exists to automatically configure FlashArray devices to Round Robin and an IO Operations Limit setting of 1 (makes FlashArray devices alternate logical paths after every I/O to that device). If no rule exists, it creates one, if one or more incorrect rule for Pure Storage FlashArrays are found it deletes them and creates a correct one. If wrong ones are found and a correct one is found it just deletes the bad ones. This will make sure if the vendor is PURE (as seen in our VPD inquiry) is in the rule, if so it will make sure the rule has Round Robin, IO Operations set to one and the model is set to FlashArray. This will make sure nothing outside of Pure Storage is affected.


  • Furthermore, if devices are found that are mis-configured for multipathing, it will make sure they are set to Round Robin and IO Operations Value of 1.


  • Automatic Space Reclamtion on VMFS 6. Checks that this is enabled on VMFS-6 volumes and enables it if not.

Note from above, this value of 1 is configurable in the script but I don’t recommend changing it.

Best Practices Checker

This script will NOT make any changes to your environment. It only looks for errors. Therefore I have a lot more going on in this script. The report that is spit out is focused on errors, so it will not tell you about things that are correct, mostly. So feel free to make it use a read only user from vCenter.


The best practice “setter” script from above specifically looks for settings that are non-default that we recommend. This one checks for pretty much everything we recommend from a host perspective and a device level. Errors found in the log will be marked with [****NEEDS ATTENTION****]. The script checks:

  • VAAI is enabled on the hosts. This means WRITE SAME, XCOPY and ATOMIC TEST & SET
  • XCOPY MaxHWTransferSize is set to 16 MB
  • Datastore heartbeating is enabled for use with ATS, not SCSI reservations
  • EnableBlockDelete is enabled


  • FlashArray iSCSI targets have our best practices configured, LoginTimeout of 30 seconds and DelayedAck is disabled. Any FlashArray IQNs found (our IQNs have FlashArray in them) are checked and ones missing these will be reported.


  • General iSCSI multipathing–any software iSCSI adapters should have at least two physical NICs bound to it, this script checks for at least two ACTIVE and COMPLIANT NICs. Any iSCSI software adapter without two of these will be reported. If there are at least two it will move forward, not reporting on inactive or non-compliant NICs, we just want to check for redundancy. Also not this does not touch hardware iSCSI for those who use that. Only software iSCSI which I would say is the majority.


  • Checks for a correct SATP rule for FlashArray multipathing. Looks for PURE as the listed vendor, the Path Selection Policy of Round Robin, the model of FlashArray and IO Operations Limit of 1. It will report if it finds missing or incorrect rules.


  • Check the devices for configurations. If a device has one or more issue it will be listed, the problematic configuration option will be marked with an asterisk in the report. It checks for Path Selection Policy of Round Robin, IO Operations Limit of 1, Atomic Test & Set mode is ATS only (meaning it does not ever use SCSI reservations) and has 4 or more logical paths. You can alter the path count minimum by changing the “hidden” variable on line 18 called $minpaths. Set this to an integer of whatever. I would discourage changing this to anything below 4 and definitely no lower than 2.


Enjoy! Please give me feedback. Also, if for some reason you do not want to upgrade PowerCLI my old scripts are still on my GitHub, with the same names with the word “legacy” in their title. They are not upgraded to do the new stuff, especially all of the checker changes. I highly recommend using these new ones.

24 thoughts on “Updated FlashArray VMware Best Practices PowerCLI Scripts”

  1. Hi Cody,

    Thank you for your invaluable work on these scripts!
    I’m waiting for the PowerCLI 6.3 R1 version of your unmapsdk 🙂



    P.S.: The Best Practices Checker link is broken(there is a typo in the ps1 file name).

  2. Hey Cody,

    Awesome blog posts and tools, thank you! One question/concern I have is with the checker script. It is my understanding that iSCSI port binding should not necessarily be used in all cases. For example, in the case of a network layout where there are multiple subnets in use for iSCSI (analogous to a ‘fabric-a’, ‘fabric-b’ in FCP world). VMware has a KB on this (2038869). Just wondering if you agree with this and if it’s worth adding an additional step(s) to you script or making at least making a special note in script about multi-subnet iSCSI configs?


    1. You’re welcome! Glad it is helpful to you. I will try to keep it up!

      This is a good point, I will add this to the post. Thank you!

  3. If want to only touch a certain cluster and the host under the cluster, change the line (113 in the one script, 115 in the other)
    $hosts= get-cluster | get-vmhost

  4. Quick question about these: can I run the best practices script in a Live environment without any impact? The best practices checker finds a few issues that need cleaning up and I was reasonably sure that the best practices script is only non-impacting changes but wanted confirmation. With our 3 arrays and a massive VM host refresh coming up, it would be much quicker to use this script if you can confirm non-impacting.
    Apologies if I have missed where this was answered.

    Kind regards,
    Neil Bell

  5. btw…shouldn’t this be 16384? …the logs say 16386

    [****NEEDS ATTENTION****]The VAAI XCOPY MaxHWTransferSize for this host is incorrect:
    This should be set to 16386 (16 MB).

    1. This is no longer necessary to change. I will be removing this from the script shortly. If you are using ESXi 6.5 U1 and VMFS 6 nothing in here is required. MaxHWTransferSize though can be kept at default for all versions

      1. though the “checker” script does check for other things that are important. But MaxHWTransferSize can be ignored

  6. When trying to run the checker script against a single host (named dc1a-host4-1) I receive the error:

    dc1a-host4-1 : The term ‘dc1a-host4-1’ is not recognized as the name of a cmdlet, function, script file, or operable program

    I changed line 109 to:
    $hosts= dc1a-host4-1

    What did I do wrong?

  7. Hello!

    I was wondering if you could expand on what isn’t needed for ESXi 6.5 U1. I’ll be setting up a new install in a week or two.


    1. Eric,

      None of this is needed if you are on 6.5 U1. Arguably EnableBlockDelete could be turned on because you would likely have some VMFS-5 datastores still, but it’s not totally required, I would focus more on moving to VMFS-6 than worrying about this setting.


  8. Thanks Cody! This will be a complete new install so I’ll be able to start with VMFS-6. Does the SATP rule still need created? (That was my main focus when I found this post.)


Leave a Reply

Your email address will not be published. Required fields are marked *