[one-users] (block) iotune support in templates

[Carlos Martín Sánchez]

Hi Stefan,

On Sun, Nov 17, 2013 at 9:46 PM, Stefan Kooman <stefan at bit.nl> wrote:

> Dear list,
>
> Recently I've been playing with OpenNebula on Ubuntu Saucy (13.10). It
> comes with libvirt-bin version 1.1.1 and qemu 1.5. One of the cool
> things libvirtd / qemu are able to do now is "block io throttling", or
> iotune as libvirt calls it. You can now define min, max, total
> KBytes/Sec for read, write and total, as wel as for IOPS/Sec. I would
> like to have support for this in OpenNebula vm templates just like there
> is for CPU (cputune). It would be nice to able to set a total maximum
> IOPS / bandwitch for a specific user/group, just like cpu, mem, images,
> #vm's, etc. (and have strict enforcement).
>
> Use cases:
>
> - prevent denial of service of virtual machines consuming too much IOPS
>   / bandwith (io starvation, storage link saturation)
> - be able to guarantee (minimal) disk IO performance. In combination with
> "per
>   user system datastores (ONE 4.4)" you can choose the right disk type
>   to satisfy latency needs.
>
> What do you think?
>
> Gr. Stefan
>
> P.s. with something like vdc-nebula in place [1], the need to restrict IO
> will be much less then in traditional io settings (very cool project
> indeed).
>
> [1]: http://blog.opennebula.org/?p=5408


That's really interesting, indeed.
Let's think of how this would look in OpenNebula.

The first and easiest option that comes to mind is to allow a new attribute
DISK/RAW, that would look like:

DISK = [
  IMAGE_ID = 7,
  RAW = "<iotune>
        <total_bytes_sec>10000000</total_bytes_sec>
        <read_iops_sec>400000</read_iops_sec>
        <write_iops_sec>100000</write_iops_sec>
      </iotune>"
]

I think this is useful by itself, to allow generic customization of the
devices in the deployment file. A similar NIC/RAW attribute would be also
easy to add.

A prettier way would be to parse the elements DISK/READ_BYTES_SEC
 DISK/WRITE_BYTES_SEC, etc. These iotune attributes could be set as
restricted attributes [1], and let the admin set defaults for each Image or
each DS, using the inherited attributes functionality introduced in
OpenNebula 4.4 [2].



Regarding the user and group quotas, that's something that I'd consider for
a second phase. If this is specific for kvm and we don't have an equivalent
for xen and vmware, I don't know if it would be acceptable to have an
exception hardcoded in the quotas:

<VM_QUOTA>
  <VM>
    <CPU>
    <CPU_USED>
    <MEMORY>
    <MEMORY_USED>
    ..
    <TOTAL_BYTES_SEC>
  </VM>
</VM_QUOTA>

Or if we should think of a more flexible definition of the quotas
mechanism. I'm thinking of something like this in oned.conf:

VM_QUOTA_DEFINITION = [
  VM_ATTRS = "/VM/DISK/TOTAL_BYTES_SEC /VM/DISK/READ_BYTES_SEC
/VM/DISK/WRITE_BYTES_SEC"
  NAME = DISK_IOTUNE
]

But this may be a bit overkill.



I opened a couple of tickets [3,4] with the features that could be added in
the short term. Thanks a lot for your feedback.

Regards,
Carlos.

[1]
http://opennebula.org/documentation:rel4.4:oned_conf#restricted_attributes_configuration
[2]
http://opennebula.org/documentation:rel4.4:oned_conf#inherited_attributes_configuration
[3] http://dev.opennebula.org/issues/2530
[4] http://dev.opennebula.org/issues/2530
--
Carlos Martín, MSc
Project Engineer
OpenNebula - Flexible Enterprise Cloud Made Simple
www.OpenNebula.org <http://www.opennebula.org/> | cmartin at opennebula.org |
@OpenNebula <http://twitter.com/opennebula>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20131203/2884c3f6/attachment.htm>