As enterprise VMware environments adopt NVMe-oF, the way ESXi selects and balances storage paths is changing. The familiar SCSI-era guidance of setting Round Robin IOPS=1 served its purpose well, but the High Performance Plug-in (HPP) used with NVMe-oF introduces new path selection schemes worth understanding. That was the reason I built a second simulator focused specifically on this comparison.

You can try the simulator here: VMware HPP Path Selection Simulator

The tool places two HPP path selection schemes side by side, LB-IOPS and LB-Latency, running the same 8K IOPS workload across the same four physical paths. The difference is how each scheme reacts when one path becomes slow but stays online. You can click Trigger Congestion to introduce latency on Path 3 and watch how each scheme responds, then Recover Path 3 to see how each handles recovery.

LB-IOPS distributes I/O based on I/O count. After a set number of I/Os on a path, it rotates to the next path, but it does not inherently know that a path has become slower. LB-Latency periodically samples the response time of each path and prefers the paths with lower measured latency, de-prioritizing (not failing) a congested path.

The key idea the simulator illustrates is that equal path utilization is not the same as optimal path selection. SAN congestion, slow drain, oversubscription, and fabric contention can make a path technically online but slow. When that happens, LB-IOPS keeps sending I/O to the degraded path and the host continues to feel the impact, while LB-Latency reduces that impact by shifting traffic toward healthier paths. Recovery is automatic, when a slow path improves, LB-Latency re-includes it on the next evaluation cycle rather than permanently discarding it.

When all paths are healthy, both schemes perform well and distribute I/O evenly. The differences only become visible under a degraded-path scenario, which is exactly the kind of dynamic runtime behavior that is hard to convey with static diagrams or configuration snippets. Observing it in real time makes the reasoning behind LB-Latency much clearer than simply reading a best-practices recommendation.

This is not to say LB-IOPS is wrong. It mirrors the proven Round Robin behavior many administrators already trust. But as NVMe-oF on HPP becomes more common, LB-Latency demonstrates an important shift: path quality matters, not just path distribution.

Reference: VMware vSphere 9.0 - HPP Path Selection Schemes