Path thrashing is when the active path for a LUN switches rapidly from one storage controller to the next. It generally results in severely degraded performance and, in extreme cases, a number of instability issues. Path thrashing does not occur with only one ESX host or single-controller storage systems.
In ESX, path thrashing most frequently occurs if the ESX multipathing policy is set to "fixed", and the storage controllers are active/passive at the back-end ("esxcfg-mpath -l" lists half the paths as "on", and the other half as "standby".) The other case is when there is a configuration issue on the storage controller, specifically that the controllers are really active/passive, but report themselves as being active/active ("esxcfg-mpath -l" returns all paths' status as "on".)
In the first case, if ESX servers are set up to have different preferred paths (i.e. Server 1 prefers to use controller A, Server 2 prefers to use controller B), they may cause the active/passive controllers to switch a LUN from one controller to the next constantly. This is a configuration problem on the ESX server and can be corrected by setting the path policy back to the default of MRU. (LUNs on active/passive controllers should always use MRU; active/active LUNs can use either MRU or Fixed, but uses fixed by default.)
The second case is a configuration issue on the storage controller and needs to be corrected there. In this case, the ESX servers will have no way of determining which is the correct path and will try to communicate on the first available one. The storage controller will then fail the path over to the controller being target. The feature that needs to be disabled is sometimes called AVT (auto-volume transfer) and you'll see mention to it in /var/log/vmkwarning if the problem occurs. In most cases, setting the host type to "cluster" resolves this, but you need to check your SAN vendor's documentation for this one.
.png "jhanekom"){kind=avatar}