A particular example is the Path Selection Plug-ins (or PSPs) for storage pathing. PSPs are part of the VMware Multipathing Module, which is called the Native Multipathing Module (or NMP). PSPs allow for highly available access from your ESXi host to your storage. The PSP that you select will determine what happens in the event that one of your storage paths has failed, and more importantly, what happens when that failure has been corrected.
Here's a table that summarizes the behavior of each PSP:
| PSP Selection | Automatic Failover? | Automatic Failback? |
| Fixed (VMware) | Yes | Yes |
| MRU (Most Recently Used) | Yes | No |
| Round Robin* | Yes | No |
The point to take away from this table is that when using the Fixed PSP, ESXi will automatically revert to the failed path when the failure has been corrected. Relative to the Change Management discussion, this failback may become a change that your client's organization wants to manage, as opposed to letting VMware automatically change paths. Whether this is a well-reasoned requirement is immaterial; a requirement is a requirement.
A Note about Round Robin
Round Robin is a special case, in that it has two modes: Active / Active and Active / Passive. These modes are determined by your storage controller configuration (e.g., if you've got two storage controllers and both are actively handling storage connections, you'll use Active / Active for Round Robin). In the event of a failure, this PSP will select the next storage path to the active controller. It will not fail back to the failed path once the failure has been corrected, though. Path changes only occur in Round Robin when the actively selected path fails.
Lots of other automation within vSphere can be discussed with regard to change management: vMotion via DRS, sDRS, even DPM (which is great, by the way! Expect a blog post on this soon). So plan accordingly and account for change management in your engineering.
