relationship between clusters and host groups
Due to circumstances beyond my control, over time and several upgrades of vSphere, there is no longer any commonality between the clusters in vSphere and what I see as host groups in the FlashArrays....
Forum Discussion
Short answer:
FlashArray API doesn’t “figure it out” from vCenter. It’s deliberately agnostic. In the ideal (and supported best-practice) world, each vSphere cluster maps 1:1 to a FlashArray host group, and each ESXi host maps 1:1 to a FlashArray host object with its initiators. That alignment makes provisioning, automation, and LUN ID consistency dead simple.
What “sane” looks like
- One FA host object per ESXi host, populated with the host’s FC WWPNs or iSCSI IQN.
- One FA host group per vSphere cluster (per array), containing those host objects; present shared VMFS datastores to the host group so every node sees the same LUN number.
- vVols nuance: you still map the Protocol Endpoint (PE) to the cluster’s host group; VASA handles per-VM vVol binding.
- If you use the Pure vSphere Plugin, it will create/update the matching host/host-group objects for you when you provision (and it keeps LUN IDs consistent across hosts).
Safe(ish) way to get back to sane (no outages)
The one hard rule: don’t rip a host out of its current host group without planning—that instantly drops access to any volumes presented via that group and can trigger PDL on the ESXi side.
A pragmatic, step-by-step approach:
Inventory reality
From FlashArray: list hosts, host groups, and connections (which volumes are connected to which host/host-group).
From vCenter: list clusters and member hosts (and which datastores they’re using).
The FA API and SDKs expose all of this; you can script it in PowerShell SDK v2 or Python.
- Define target state
- Decide your naming (e.g., host objects = ESXi shortnames; host groups = cluster names).
- Create any missing host groups that mirror clusters; create any missing host objects for ESXi hosts. (The Pure Plugin or Cody’s helper cmdlets can scaffold this for you.)
- Migrate host membership one host at a time
- For each ESXi host, temporarily connect the currently-used datastore volumes directly to the host (host-level connections) so the host continues to see its LUNs even after you change groups.
- Move the host into the correct host group (the one that matches its vSphere cluster).
Connect the same datastore volumes to the new host group, confirm the host sees the new group-based paths and stable LUN IDs, then remove the temporary host-level connections. (FA supports connections to hosts and host groups; group connections keep LUN IDs identical across the cluster.)
Repeat for the next host.
For vVols
Ensure the Protocol Endpoint is mapped to the cluster’s host group; datastore(s) will enumerate via VASA automatically.
Provisioning going forward
Use the Pure vSphere Plugin to create/expand datastores; it will place volumes on FA and connect them to the right host group automatically—no more shell-games.
Quick audit helpers
Pure vSphere PowerShell module & SDK2: there are cmdlets and examples that build FA host/host-group objects straight from vCenter clusters (e.g., New-PfaHostGroupFromVcCluster), and SDK2 samples for managing hosts/host groups.
https://blog.purestorage.com/purely-technical/configuring-an-esxi-cluster-for-storage-provisioning-for-a-flasharray-via-powershell/
Hi guys, thanks for all the suggestions. To clarify more and not throw anyone under the bus - if anyone has worked with "composable infrastructure", it allows people to rebuild blades and sometimes the WWPNs don't always remain. In most cases the WWPNs are still aligned with host names. The problems I see are that they decided to A) rename clusters and B) sometimes rename hosts and C) moved hosts between renamed clusters. All this came about largely due to not doing in-place vSphere upgrades but each "major" upgrade was a greenfield and thereby left to the whims of the virtualization team to build things "different" than was seen in the old vCenters, so, at one time I had everything 1:1 matching clusters to host groups, names, etc. and I (previously) did all provisioning via the plugin (because why wouldn't you). But over years (I delegated much, took eyes off the environment some) and several upgrades it is no longer recognizable to me and yes, I suspect I will have to methodically go through each environment to verify WWPNs match hostnames, etc. The plugin seems to be able to do the basics - resize datastores for example but I'm leery of updating host groups and removing/adding hosts because of the disconnect. Another example - as you know clusters can have spaces in names - host groups (at least from what I see in 6.5 purity) so "how does it know?". Should I convince the VMware team to standardize and name-match or what?
thanks
Yeah, that makes perfect sense, gear can definitely throw things off once WWPNs and hostnames start drifting. What you’re seeing happens a lot when teams rebuild vCenters and clusters instead of upgrading in place. The Pure plugin really depends on consistent naming and WWN alignment, so once that’s gone, it’s smart to be careful about using it for host group changes.
If you can, get the VMware team to standardize names again and use same cluster and host naming across vCenter and the array. It’ll make the plugin usable and predictable. In the meantime, I’d pull a current WWPN list from both sides and clean it up manually. Once you’ve got that alignment back, it’ll save a ton of confusion later.
Purity 6.5 doesn’t like cluster names with spaces. Stick to clean alphanumeric names if you can. Until things are standardized, I’d handle host group edits directly from the array CLI or REST rather than through the plugin.
Try to push for naming consistency. Once that’s fixed, everything else (plugin ops, automation, reporting) falls back into place. Also push for change management and CMDB changes - that will make your life easier....
Last advise, if people do not know how to use plugins, do not allow access...
