SLA feature for storage I/O bandwidth

[Doron Fediuck]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Doron Fediuck" 
> Cc: "Mei Liu" <liumbj at linux.vnet.ibm.com>, arch at ovirt.org
> Sent: Wednesday, June 5, 2013 9:45:43 PM
> Subject: Re: SLA feature for storage I/O bandwidth
> 
> 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.
> 

Network profile contains information on the connection of the VM to the
network, which is the vNIC. So using this concept, the disk is the
connection of a storage domain to a VM, thus disk profile holds the
information on this connection. So in this view permissions would be kept
at storage domain level, and we'll need to handle the profile when moving
(cloning?) a disk between SD's.