Skip to main content
Pure1 Support Portal

FlashArray Configuration

Host and Host Group Creation

This section describes the recommendations for creating provisioning objects (called hosts and host groups) on the FlashArray. The purpose is to outline the proper configuration for general understanding. It is important to note though, that the FlashArray vSphere Web Client Plugin will automate all of the following tasks for you and is therefore is a recommended mechanism for doing so.

The FlashArray has two object types for volume provisioning, hosts and host groups:

  • Host—a host is a collection of initiators (iSCSI IQNs or Fibre Channel WWNs) that refers to a physical host. A FlashArray host object must have a one to one relationship with an ESXi host. Every active initiator for a given ESXi host should be added to the respective FlashArray host object. If an initiator is not yet zoned (for instance), and not intended to be, it can be omitted from the FlashArray host object. Furthermore, while the FlashArray supports multiple protocols for a single host (a mixture of FC and iSCSI), ESXi does not support presenting VMFS storage via more than one protocol. So creating a multi-protocol host object should be avoided on the FlashArray when in use with VMware ESXi.

    In the example below, the ESXi host has two online Fibre Channel HBAs with WWNs of 20:00:00:25:B5:11:11:1C and 20:00:00:25:B5:44:44:1C. volumes1.png
  • Host Group—a host group is a collection of host objects. Pure Storage recommends grouping your ESXi hosts into clusters within vCenter—as this provides a variety of benefits like High Availability and Dynamic Resource Scheduling. In order to provide simple provisioning, Pure Storage also recommends creating host groups that correspond to VMware clusters. Therefore, with every VMware cluster that will use FlashArray storage, a respective host group should be created. Every ESXi host that is in the cluster should have a corresponding host (as described above) that is added to a host group. The host group and its respective cluster should have the same number of hosts. It is recommended to not have more or less hosts in the host group as is in the cluster. While it is supported to have an unmatching count, it makes cluster-based provisioning simpler, and a variety of orchestration integrations require these to match. So it is highly recommended to do so.

BEST PRACTICE: Match FlashArray hosts groups with vCenter clusters.

Be Aware that moving a host out of a host group will disconnect the host from any volume that is connected to the host group.  Doing so will cause PDLs to any datastores that are using the Volumes connected to that Host Group.

Setting the FlashArray “ESXi” Host Personality

DO NOT make this change online. If an ESXi host is running VMs on the array you are setting the host personality on, data unavailability can occur. A fabric logout and login may occur and accidental permanent device loss can occur. To avoid this possibility, only set this personality on hosts that are in maintenance mode or are not actively using that array.

In Purity 5.1 and later, there is a new host personality type for VMware ESXi hosts. Changing a host personality on a host object on the FlashArray causes the array to change some of its behavior for specific host types.

In general, we endeavor inside of Purity to automatically behave in the correct way without specific configuration changes. Due to a variety of host types supported and varying requirements (a good example is SCSI interaction for features like ActiveCluster) a manual configuration was required.

In Purity 5.1, it is recommended to enable the “ESXi” host personality for all host objects that represent ESXi hosts.

The ESXi personality does the following things as of Purity 5.1.0:

Makes the FlashArray issue a Permanent Device Loss SCSI sense response to ESXi when a pod goes offline due to a mediator loss. If this is not set, no response is sent and vSphere HA does not detect the failure properly and will not restart VMs running on the failed hosts.

ESXi uses peripheral LUN IDs instead of flat LUN IDs—this changes how ESXi views any LUN ID on the FlashArray above 255. Since ESXi does not properly interpret flat LUN IDs, it sees LUN ID higher than 255 to be 16,383 higher than it should be (256 is seen as 16,639) which is outside of the supported range of ESXi. Setting the ESXi personality on the FlashArray for a given host switches the FlashArray LUN methodology to peripheral, allowing ESXi to see LUN IDs higher than 255.

While this personality change is currently only relevant for specific ActiveCluster environments and/or environments that want to use higher-than-255 LUN IDs, it is still recommended to set this on all ESXi host objects. Moving forward other behavior changes for ESXi might be included and doing it now ensures it is not missed when it might be important for your environment.

BEST PRACTICE: Set FlashArray host objects to have the FlashArray “ESXi” host personality when using Purity 5.1 or later.

The ESXi host personality can be set through the FlashArray GUI, the CLI or REST. To set it via the GUI, click on Storage, then Hosts, then the host you would like to configure:


Next, go to the Details pane and click the vertical ellipsis and choose Set Personality…:


Choose the radio button corresponding to ESXi and then click Save.




Connecting Volumes to Hosts 

A FlashArray volume can be connected to either host objects or host groups. If a volume is intended to be shared by the entire cluster, it is recommended to connect the volume to the host group, not the individual hosts. The makes provisioning easier and helps ensure the entire ESXi cluster has access to the volume. Generally, volumes that are intended to host virtual machines, should be connected at the host group level.

Private volumes, like ESXi boot volumes, should not be connected to the host group as they do not (and should not) be shared. These volumes should be connected to the host object instead.

Pure Storage has no requirement on LUN IDs for VMware ESXi environments, and users should, therefore, rely on the automatic LUN ID selection built into Purity.