Migrating VMware FC and NFS Datastores Without an Outage
A VMware environment has 12 ESXi hosts, 300 VMs, and two independent 16 Gb FC fabrics. The old FC array is being replaced by an OceanStor Dorado. Each ESXi host has two single-port HBAs. The current zones are single-initiator/single-target: HBA-1 is zoned to one old array port, HBA-2 to another. The new array exposes four target ports per controller. A separate NFS datastore on an old NAS holds 80 TB of VMs and must move to the new platform. The migration window is six weekends; each weekend can tolerate one storage path loss but not a VM outage. The team plans to use Storage vMotion for running VMs. Change control requires that every LUN have at least four active paths and that no single fabric loss causes an all-paths-down event. The network team can provide two 25 GbE links on a dedicated storage VLAN.
1. Design the FC zoning and multipath layout so each LUN has at least four active paths and a single fabric loss does not cause all-paths-down. State the zone members and the expected path count.
Read the worked answer
Use single-initiator, multiple-target zones, one zone per host HBA. On fabric A, zone HBA-1 to one target port on controller A and one target port on controller B. On fabric B, zone HBA-2 to one target port on each controller. Do not put both HBAs in one zone, and do not zone multiple initiators together.
With two HBAs and one target port per controller per fabric, each LUN has 2 HBAs × 2 controllers = 4 paths. If you zone two target ports per controller per fabric, it has 8. The four-path minimum is met with one target port per controller per fabric. Because the new array exposes four ports per controller, spread hosts across ports to avoid oversubscription; do not zone every host to every port.
Confirm ALUA target-port group IDs so paths are active/optimized versus active/non-optimized. In ESXi, verify the SATP and PSP claim, for example ALUA with Round Robin, and that each LUN shows the expected naa ID and four or more paths. Losing one fabric should leave two paths to both controllers, not zero. Test by disabling one HBA or one switch port before migrating production VMs.
2. Sequence the migration of the 300 VMs and the 80 TB NFS datastore. What checkpoints must pass before each weekend starts?
Read the worked answer
Pre-stage the new array: create LUNs, host groups, mappings, zones, and NFS exports; install or verify UltraPath or native MPIO; confirm ALUA and path counts. For FC VMs, use Storage vMotion in waves, not all at once. Before each weekend, confirm the new datastore is visible on every host with the expected paths; run a test VM migration and a path-failure test; verify snapshot and backup jobs are aware of the new datastore; check free capacity and queue depth.
Migrate low-risk VMs first, then database and application VMs with application-owner validation. For NFS, mount the new export on all hosts, test permissions and throughput from a representative host, then Storage vMotion VMs; keep the old export read-only for a rollback period. Do not decommission old paths until all VMs are moved and at least one full backup and restore test passes.
At the end of each weekend, record path state, error logs, and a performance baseline. If a path-loss test fails, stop and fix zoning or claim rules before moving more VMs. The six-weekend limit is a schedule constraint, not a reason to combine NFS cutover and FC cutover if validation is incomplete.
3. What NFS-specific design and validation points would you include for the 25 GbE storage VLAN?
Read the worked answer
Use a dedicated storage VLAN with two 25 GbE links per host in a bond mode supported by VMware and the switch. Match MTU end to end: if jumbo frames are used, set 9000 on the ESXi vmkernel, physical switch, and array interfaces, and test with large packets. A mismatch causes intermittent hangs that look like array latency.
Confirm NFS version and locking: NFSv3 with the appropriate lock service, or NFSv4.1 if supported by the array and required by the design. Set exports with least-privilege host or network access, root-squash policy, and consistent UID/GID mapping. Validate throughput with a representative read/write test, not just ping; check retransmits, drops, and NIC errors.
For path loss, test one link down and confirm NFS traffic continues. Keep NFS and FC design separate: do not assume FC multipath covers NFS. Before cutover, test Storage vMotion over NFS and a restore of a test VM. Document rollback to the old NAS and keep it read-only until validation completes.