5 Responses

  1. Irfan Ahmad
    Irfan Ahmad at |

    Hey Michael,

    Reading your post was a walk down memory lane. I remember implementing many of the details you've described in your post while in the DRS team. Storage I/O Control is an amazing feature and I really think that people who run highly consolidated storage systems should upgrade to get access to it. Just set it and forget it.

    Reply
  2. Obaid
    Obaid at |

    Hello Michael,

    Apologies for being a bit pedantic here…however, the statement on QD being ignored when there are multiple VM's per datastore, had me revisit Duncans's aritcle: http://www.yellow-bricks.com/2011/06/23/disk-sche
    If I understand correctly, QD value is still relevant even with multiple VMs per Datastore. vmkernel will start throttling the queues to the DSNRO value only during high i/o times and when a certain condition is met (i.e. Disk.SchedQControlVMSwitches). And when the situation is normalized (i.e Disk.SchedQControlSeqReqsm is met) it reverts to the original QD vaule.

    now I maybe slightly/completely wrong here, but that's the point of posting this comment, to get good understanding of the concept 🙂

    Reply
  3. Obaid
    Obaid at |

    Thanks Michael, appreciate you taking time to reply. I completely agree, when enabled SIOC will eliminate the need for manual calculations and monitoring. Although IMHO, the qlogic doc does not seem to be entirely correctly on implying that QD is ignored when we've multiple VMs issuing I/O to a single LUN. As Duncan's article clearly states, "When two or more virtual machines issue I/O to the same datastore DSNRO kicks in. However it will only throttle the queue depth when the VMkernel has detected that the threshold of a certain counter is reached".

    So In a scenario with default values and without SIOC enabled (because of licensing for example), I think vmkernel can throttle the no. of I/Os up-and-down between 64 and 32 depending on the load and the counters on the parameters(shared earlier).

    I have found the following vSphere blog quite informative as well on the topic: http://blogs.vmware.com/vsphere/2012/08/advanced-

    Reply

Leave a Reply