How to Minimize vMotion Latency with a Conservative DRS Migration Threshold

Quick Answer

Setting the DRS migration threshold to conservative (level 1) is correct because it directly targets the actual cause of the latency spikes: vMotion migrations happening on the same host as the latency-sensitive trading VM. The migration threshold controls how large an imbalance score has to be before DRS acts, and an aggressive setting means DRS will move VMs around for even minor imbalances, generating frequent vMotion activity. Every vMotion consumes CPU and memory bandwidth on both the source and destination host while memory state is copied over, and on a host running a workload as sensitive as TRADER-01, that contention is enough to produce noticeable latency spikes even though the trading VM itself was never the one being migrated. Moving the threshold to conservative raises the bar for DRS to intervene, so migrations happen far less often, cutting down on this background interference without touching TRADER-01's own vCPU or memory allocation, and without requiring new hardware. Other approaches, like resizing the VM or disabling DRS entirely, would either not address the root cause or sacrifice the cluster's ability to balance load when it genuinely needs to. When a scenario describes a latency-sensitive VM suffering brief performance dips that line up with DRS activity elsewhere on the same host, look for an answer that reduces migration frequency rather than one that changes the sensitive VM's own configuration.