A factory MDS is already running a domain ID in VSAN 10. An engineer configures a different static domain ID for VSAN 10 only. Hosts keep their current FCIDs, and the running domain ID does not change. What applies the new static domain ID?
Select an answer to reveal the explanation.
Short Explanation
You changed the street number on the form, and the sign on the building is the old one until you shut the street. A new static domain ID does not replace the running domain ID by itself. A disruptive domain restart of that VSAN applies it, and the devices in that VSAN log out.
Full Explanation
The runtime domain ID is what FCIDs are built from. Configuring a different static domain ID stages the value you want. It takes effect when the domain manager restarts disruptively for that VSAN, which forces the devices in VSAN 10 to log in again and can change their FCIDs. Other VSANs keep their own domain IDs. A nondisruptive domain restart does not replace a domain ID that is already running, so it will not produce this change and it is not a way to avoid the logouts. Activating a zoneset enforces who may talk. It does not assign domain IDs. A CFS commit distributes pending fabric data such as device aliases. It does not install a static domain ID. Caveat: after the disruptive restart, anything that was zoned or masked by FCID instead of by PWWN can miss. Prefer PWWN zoning so the new FCIDs do not matter. Operational check: compare the configured static domain ID with the runtime domain ID for VSAN 10 after the disruptive restart, and confirm VSAN 20 still has its previous domain ID.