SLA feature for storage I/O bandwidth

[Itamar Heim]

On 06/05/2013 05:26 PM, Doron Fediuck wrote:
> Hi Mei Liu,
> sorry for the delay.
>
> I agree that the advanced approach is getting complicated, and
> that we can allow mom to control parts of it.
> Having that said, I'd still want you to look at the bigger picture
> of a VM QoS.
> Please refer to the discussion we had on network QoS, where we
> managed to define it in a way which going forward will be more
> user friendly on the one hand, but can be translated into mom-policy
> on the other hand.
> See: http://lists.ovirt.org/pipermail/engine-devel/2013-June/004764.html
>
> As you can see there, we defined a network profile, which includes a QoS
> element. Going forward this element will be taken from a policy, which
> will hold additional QoS aspects such as I/O, CPU and memory. In addition
> to that, the policy may include a reference to a quota allocation as well
> as other SLA related properties such as HA.
>
> So in this light, I'd like to see a disk-profile, which holds the QoS element
> and possibly other storage related properties, such as mom-auto-tune arguments.
> So once an admin sets this profile, the VM creator (or disk creator) can
> choose the relevant profile he needs for the disk and assign it to the disk.
> Once we have this in place, the engine will provide this policy to mom on
> VM creation, and mom will enforce I/O (in this case, but also network and
> others going forward) on the VM based on the policy it got. If the policy
> allows I/O auto-tuning, then mom will manage it for that disk.
>
> The benefits to this approach are that it's more holistic from system
> perspective. It should allow easy management and simple defaults which
> users should not deal with unless they have the relevant permissions such
> as disk creators.
>
> So in this context, I'd love to see a definition of disk or image profile,
> and the storage QoS element it holds. The VDSM API should already support
> policy updates for mom, so we only need to introduce the libvirt API elements.
>
> Feedback is more than welcomed.

I like the concept of using disk profile similar to network profiles.
how were you envisioning managing these entities for disks?
for networks, iiuc, the profile are defined per network, then 
permissions are defined on them (which users can use each profile, per 
network).
where would disk profiles be defined? storage domain? system level? etc.