In ESX 4.1, VMware added one of the best things in a shared storage environment management control, Storage IO Control (SIOC). This is a HUGE addition as runaway IO has always been a danger to the VMware community storage cluster. Storage IO control not only allows VMware managers the ability to regulate the IOPS an individual guest can consume, but it also allows VMware managers the ability to limit the guests ability to cause impacting IO and hurt the response times of other “well behaving” guests.
This is a great youtube video showing an example.
Once you enable storage IO control you do limit the maximum performance any one VM guest can achieve, however it’s at with the benefit we have also noticed end users no longer “feel” services being slow due to a run away process or greedy DB operation. Storage IO Control help “remove the peaks” from the IO load, at the cost of adding time to the IO operation. When a large IO load operation is under way, it is throttled so the other guests on the LUN is not “starving” for IO attention.
During our backup operations, the SAN is completely consumed, however it’s much more responsive with IO control enabled. If you have many VM’s sharing a LUN/disk pool, I recommend turning this option on. If you have one LUN/disk pool per server, IO control is not recommended. This is a LUN by LUN option not global.
Here you can see some of the ISCSI Datastores that have the IO control enabled.
Choose “properties” of the storage volume then enable the option.
We have not neededto diverge from the default setting of 30ms.
Using Storage IO control has limited the “pain” users feel from larger IO operations induced from other guests.
The bottom line, you will no longer see “monster IO” VM guests causing calls into the
support system with users having a bad experience due to IO run away.
