Storage I/O Control

Quick Answer

Configuring Storage I/O Control and setting the database VM's shares to High is correct because shares are specifically the mechanism SIOC uses to decide who gets priority once it detects congestion on a shared datastore, and here the real signal is that other VMs on the datastore are idle, meaning contention is not actually happening most of the time. SIOC only starts enforcing anything once the datastore's measured latency crosses its threshold; when there is no real congestion, all VMs get normal access regardless of their share values, so this approach does not waste resources or artificially cap anything during quiet periods. It only matters, and only kicks in, during the moments when contention actually occurs, at which point the higher share value ensures the database VM is served first. This differs from manually setting hard I/O limits on other VMs, which caps their throughput permanently rather than adaptively, and from just tuning the latency threshold alone, which controls when SIOC intervenes but not who benefits once it does; the prioritization job specifically belongs to shares. It is also distinct from Storage DRS, which addresses space and I/O balance across datastores over time rather than prioritizing a specific VM's access in real time. When a scenario asks how to guarantee a specific VM gets I/O priority during contention on shared storage, shares configured through SIOC is the mechanism built for exactly that.