Planning an NSX 3.2.3 to 4.1 Upgrade With Legacy N-VDS Hosts
Contoso runs NSX 3.2.3: three managers, Edge cluster EDGE-A with four bare-metal edge nodes in DC-1, Edge cluster EDGE-B with two VM-form-factor edge nodes in DC-2, and 50 ESXi hosts. Forty hosts are prepared for NSX on VDS 7.0 U3. Ten older hosts still use an N-VDS created when the platform was first deployed, and those hosts also run the busiest database cluster. vCenter is 7.0 U3. The team wants to reach NSX 4.1 in a single four-hour change window and has accepted four hours of edge-service downtime. East-west traffic between application tiers must not be interrupted.
1. What must be cleared before the upgrade can start, and what evidence would you demand before booking the window?
Read the worked answer
Hard blocker: the N-VDS hosts. NSX 4.0 removed support for N-VDS on ESXi hosts, so the ten hosts on N-VDS cannot be upgraded to 4.1 as they stand. They must first be migrated to a VDS at version 7.0 or later (host switch migration), which is itself a disruptive per-host operation and should be done as its own change with a rollback plan. That work has nothing to do with the upgrade window and should be scheduled weeks earlier - especially since those hosts run the busiest database cluster.
Evidence to demand:
- A row-by-row read of the VMware interoperability matrix for 3.2.3 to 4.1. Do not assume a direct hop exists; if the matrix requires an intermediate release, the plan changes completely.
- VDS version on every host cluster, not just the forty that are already compliant.
- Current NSX version of every transport node and edge node, so nothing is silently lagging.
- Confirmation that vCenter 7.0 U3 is supported with the target NSX release, and that the edge form factors in both clusters are supported.
- A successful, verified configuration backup taken immediately before the window.
If any of these is missing, the window should be cancelled rather than started - a failed upgrade at the manager tier is far more expensive than a rescheduled window.
2. Given the four-hour window, sequence the upgrade and state explicitly what will not fit. Where does the accepted edge downtime land?
Read the worked answer
Sequence:
- Take and verify a configuration backup; confirm the SFTP target is writable.
- Managers, one node at a time, waiting for cluster health between nodes. The cluster stays available at reduced redundancy.
- EDGE-A (active-active Tier-0, four nodes): upgrade in batches of two so ECMP capacity and BFD adjacencies survive. This should be non-disruptive.
- EDGE-B (two VM edges, presumably an active-standby pair serving a stateful Tier-1): upgrading both nodes takes the pair down. This is where the accepted edge downtime lands - schedule it as a declared outage, not as a surprise.
- Hosts, in maintenance-mode batches per vSphere cluster, with the upgrade coordinator driving it.
What will not fit: the host phase. Fifty hosts at even 15 minutes each of drain, remediate, reboot, and validate is over twelve hours of serial work before any troubleshooting. Four hours covers steps 1-4 comfortably and perhaps one host cluster.
Recommendation: window 1 = backup, managers, both edge clusters; windows 2..n = hosts in waves per cluster. Do not start the host phase with less than 90 minutes left; an interrupted host upgrade leaves a transport node in an undefined state.
3. During the host phase, one host fails at the NSX installation step with a VIB conflict and the upgrade coordinator marks it as failed. What is the correct judgement call - retry, skip, or roll back?
Read the worked answer
Do not skip and do not panic-roll-back.
- A failed host in a mixed-version fleet is tolerable transiently - NSX supports hosts interoperating across versions during an in-progress upgrade - but it is not a state to leave running for days. Set a fix-or-rollback deadline.
- Put the host into maintenance mode first. Attempting to remediate a transport node that is still carrying VM traffic turns a software problem into an outage.
- Then diagnose: check the host's NSX installation logs for the specific VIB conflict, confirm no stale VIB from a previous release is present, and confirm the host's ESXi build is on the supported baseline. Most VIB conflicts at this step are a leftover component from the older version or an out-of-baseline host, not a fault in the target release.
- Retry the host upgrade through the coordinator after remediation, once, with the host still in maintenance mode.
- If the second attempt fails, remove the host from NSX, remediate it as a clean host, and re-prepare it as a transport node at the new version. That is faster and safer than fighting an in-place upgrade.
Escalate to rollback only if the manager or edge tier is affected - a single host is a local problem with a local fix.