VMware ESXi cluster on a Dell EMC Unity SAN: build, LUNs and FC zoning

A new virtualisation platform fails in predictable ways: boot drives without redundancy, inconsistent host settings, LUNs that are not visible to every host, and zoning typos. This guide walks through a clean build of a vSphere cluster on Dell servers with a Dell EMC Unity array over dual Fibre Channel fabrics. Names, sizes and identifiers are placeholders.

1. Server preparation and ESXi installation#

1. Firmware. Boot each server into its lifecycle controller, mount the vendor-customised ESXi image through the remote management virtual media, and update firmware. Make sure the firmware package matches the server model; the wrong package can fail the update.
2. Boot disks. Create a RAID-1 virtual disk across the two boot drives. Redundancy for the hypervisor boot device is cheap, and reinstalling a host after a single disk failure is not.
3. Install ESXi onto that virtual disk, then reboot.
4. Initial configuration: management IP, DNS with both A and PTR records for each host, NTP servers, and domain membership if your design needs it.
5. BIOS and security: apply the vendor-supported power profile for the workload. Enable UEFI Secure Boot only when the server, firmware, boot mode, ESXi build, drivers and operational recovery process support it; remediate incompatible VIBs first and retain tested console recovery access.

Rename each host's local datastore with a consistent scheme such as <hostname>-local, so the purpose is obvious in the inventory.

2. Host hardening with PowerCLI#

Apply a version-matched baseline only to the intended cluster. Connect to the expected vCenter, select the cluster explicitly, review the resulting host list, and export current values before changing anything. Advanced-setting names, accepted values and security guidance differ by ESXi/vSphere release; absence of a setting is not a reason to create it blindly.

$expectedVCenter = $env:APPROVED_VCENTER
$clusterName = $env:APPROVED_CLUSTER
$evidenceDir = $env:PROTECTED_EVIDENCE_DIRECTORY
if ([string]::IsNullOrWhiteSpace($expectedVCenter) -or [string]::IsNullOrWhiteSpace($clusterName)) { throw 'Set the approved vCenter and cluster environment variables' }
if (-not (Test-Path -LiteralPath $evidenceDir -PathType Container)) { throw 'Protected evidence directory is unavailable' }

$vi = Connect-VIServer -Server $expectedVCenter
if ($vi.Name -ne $expectedVCenter) { throw 'Connected vCenter does not match approved scope' }
$matches = @(Get-Cluster -Server $vi | Where-Object Name -CEQ $clusterName)
if ($matches.Count -ne 1) { throw "Expected exactly one target cluster; found $($matches.Count)" }
$cluster = $matches[0]
$hosts = @(Get-VMHost -Server $vi -Location $cluster)
if ($hosts.Count -eq 0 -or @($hosts | Where-Object ConnectionState -ne 'Connected').Count -ne 0) {
  throw 'Target host inventory is empty or contains a disconnected host'
}
$hosts | Sort-Object Name | Select-Object Name,Id,ConnectionState,Version,Build |
  Export-Csv -NoTypeInformation -LiteralPath "$evidenceDir\hosts-before.csv"

$settingNames = @(
  'Security.PasswordQualityControl',
  'UserVars.ESXiShellTimeOut',
  'Security.AccountUnlockTime',
  'Net.BlockGuestBPDU'
)
$before = @($hosts | Get-AdvancedSetting -Name $settingNames)
if ($before.Count -ne ($hosts.Count * $settingNames.Count)) {
  throw 'One or more settings are absent or ambiguous; verify the version-matched baseline'
}
$before | Select-Object @{N='Host';E={$_.Entity.Name}},Name,Value |
  Export-Csv -NoTypeInformation -LiteralPath "$evidenceDir\advanced-settings-before.csv"

# Apply only values approved for every exported host version, one setting at a
# time, then export the same fields to advanced-settings-after.csv and compare.
# $before | Where-Object Name -CEQ '<approved-setting>' |
#   Set-AdvancedSetting -Value '<approved-value>' -Confirm:$false

This illustrates scoping, not a universal hardening baseline. Pre-create and protect the evidence directory, record the expected vCenter certificate/thumbprint under the organisation's trust procedure, and compare the exported host names and IDs with the approved change before uncommenting a mutation. Abort on duplicate cluster names, an unexpected vCenter, mixed unsupported host versions, absent settings or an inventory mismatch. Validate every key and value against the security configuration guide for the installed release family, use -WhatIf where supported, stage one setting on one host, and export before/after values. Never pipe an unscoped Get-VMHost into a mutating cmdlet.

3. Cluster settings#

4. Storage pool and LUNs on Unity#

Design the pool from workload measurements, fault-domain requirements, rebuild exposure, drive type and the capabilities of the exact Unity model and OE release. Do not assume that RAID-5 or a manually assigned hot spare is an appropriate default: traditional and dynamic pools use different spare-capacity and RAID-width models.

Before creating LUNs, use Unisphere or the uemcli help installed for the array's OE release to confirm the object path, pool selector, size units, thin-provisioning behavior and supported data-reduction options. The following is an operation outline, not asserted command syntax:

uemcli -d UNITY_MANAGEMENT_ADDRESS -u APPROVED_USER VERSION_VERIFIED_LUN_CREATE_OPTIONS

Use a supported credential mechanism that does not place the password on the command line. Capture the proposed name, pool, capacity, host access and feature settings for peer review, then verify the created object before mapping it.

Keep names meaningful and tied to their purpose. Separate LUNs used for VMFS datastores from LUNs presented as raw device mappings or shared cluster volumes.

Enable data reduction#

Data-reduction availability, terminology, prerequisites and performance effects depend on the Unity model, pool and OE release. Confirm support and sizing guidance before enabling it. Avoid a loop that mutates several LUNs until one LUN has been changed and observed successfully.

# Pseudocode: derive the supported syntax from `uemcli ... help` for this array.
INSPECT_ONE_LUN_AND_CONFIRM_CURRENT_SETTINGS
SET_ONLY_REVIEWED_DATA_REDUCTION_OPTIONS_ON_THAT_LUN
VERIFY_HEALTH_CAPACITY_PERFORMANCE_AND_RESULT

Schedule and monitor the change according to Dell's guidance for the exact platform. Do not claim it is online, non-disruptive or limited to off-peak impact without that version-specific confirmation.

5. Fibre Channel zoning on both fabrics#

Use the zoning pattern approved by both Dell and the switch vendor for the installed versions. Single-initiator zoning means no zone contains initiators from two hosts; some standards additionally require one initiator and one target per zone. Preserve fabric independence: an HBA port and target ports from fabric A must not be mixed with fabric B.

Brocade-style object definitions for fabric 1 are shown below with documentation-only WWPNs. Command names and activation workflow vary by Fabric OS release, so treat this as reviewed pseudocode and do not paste it into a switch session:

alicreate "ARRAY_CtrlA_P1", "50:00:00:00:00:a0:00:01"
alicreate "ARRAY_CtrlB_P1", "50:00:00:00:00:b0:00:01"
alicreate "host01_P1",      "10:00:00:00:00:00:01:01"
alicreate "host02_P1",      "10:00:00:00:00:00:02:01"

zonecreate "z_host01", "host01_P1;ARRAY_CtrlA_P1;ARRAY_CtrlB_P1"
zonecreate "z_host02", "host02_P1;ARRAY_CtrlA_P1;ARRAY_CtrlB_P1"

# Add zones to the reviewed existing or new configuration.
# Show and peer-review the effective configuration diff.
# Save and activate through the approved change procedure.

Then repeat on fabric 2 with the _P2 aliases and the other array ports.

Notes:

• Never replace an existing effective configuration merely to add zones. Determine the active/effective configuration and use the Fabric OS procedure for modifying it safely; have a rollback and out-of-band management path before activation.
• Verify every WWPN before saving. A single wrong character can leave a host with no storage path.
• Keep the alias naming consistent (<host>_P1, <host>_P2, <array>_<ctrl>_<port>).
• Make and validate the change on one fabric at a time while the other fabric remains healthy. Confirm path loss and recovery before proceeding to the second fabric.
• Before touching either fabric, export the defined and effective zoning configuration, switch/domain identities, aliases, zones, name-server logins and current host paths to protected change evidence. If an alias, WWPN, active configuration or target fabric is absent or resolves more than once, abort rather than guessing.

6. Register hosts and map LUNs#

On the array, register each initiator against the correct host record and map only the LUNs that host or cluster is authorized to access. Then rescan storage on every ESXi host, create VMFS datastores where needed, and confirm every intended host sees each shared LUN with the expected paths, canonical identifier and supported multipathing policy. Do not present raw/shared application LUNs broadly merely because VMFS datastores are cluster-wide.

7. Validation checklist#

• Both fabrics show the host and array ports logged in.
• Each host has the expected active paths to each LUN.
• vMotion between hosts works; HA test restarts a VM on another host.
• NTP and DNS resolve consistently on all hosts.
• Hardening settings are applied and recorded.
• Datastore and host naming follow the agreed convention.

8. Rollback and evidence#

• Record vCenter identity, cluster MoRef, host names/IDs/build families, cluster configuration, switch configuration, host profiles or desired-state status, advanced-setting before/after exports, Unity object IDs and host mappings, LUN canonical IDs, path states, and both fabrics' defined/effective zoning before and after the change.
• For host settings, restore only the exported value for the same host ID and setting after checking whether a reboot or service restart is required. Do not replay a CSV blindly across another cluster or release family.
• For networking, retain management access while migrating one physical uplink and one host at a time. Roll back to the recorded standard-switch or vDS configuration through the tested console/vCenter recovery path if validation fails.
• For zoning, leave the healthy fabric unchanged, restore the previously saved effective configuration using the Fabric OS procedure for that installed family, and verify paths before changing the second fabric. Never delete shared aliases or zones without a dependency check.
• For Unity mapping, unmap only the newly added, positively identified host/LUN relationship if no VMFS, RDM, clustered application or other consumer has begun using it. LUN deletion and pool changes are not routine rollback actions; preserve the object and escalate when usage is uncertain.
• EVC and Secure Boot rollback can require VM or host power cycles and may affect compatibility. Use the release-matched VMware procedure and an approved outage rather than promising live reversal.

Command names, APIs, accepted values and UI workflows vary across vSphere/ESXi, PowerCLI, Unity OE and Fabric OS release families. Resolve syntax from the installed product help and the vendor documentation for that family; do not infer commands from a different major family or fabricate a minor-version prerequisite.

Vendor references#

• VMware vSphere documentation
• VMware PowerCLI documentation
• Dell Unity documentation
• Brocade Fabric OS documentation

Check command syntax and feature availability against the vendor documentation for your array model, OS version and vSphere release.

Need a storage, zoning or vSphere design reviewed before go-live? See Managed Infrastructure Operations or start a project.