<div dir="ltr">Hi Stefan,<div><br></div><div class="gmail_extra"><div class="gmail_quote">On Sun, Nov 17, 2013 at 9:46 PM, Stefan Kooman <span dir="ltr"><<a href="mailto:stefan@bit.nl" target="_blank">stefan@bit.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Dear list,<br>
<br>
Recently I've been playing with OpenNebula on Ubuntu Saucy (13.10). It<br>
comes with libvirt-bin version 1.1.1 and qemu 1.5. One of the cool<br>
things libvirtd / qemu are able to do now is "block io throttling", or<br>
iotune as libvirt calls it. You can now define min, max, total<br>
KBytes/Sec for read, write and total, as wel as for IOPS/Sec. I would<br>
like to have support for this in OpenNebula vm templates just like there<br>
is for CPU (cputune). It would be nice to able to set a total maximum<br>
IOPS / bandwitch for a specific user/group, just like cpu, mem, images,<br>
#vm's, etc. (and have strict enforcement).<br>
<br>
Use cases:<br>
<br>
- prevent denial of service of virtual machines consuming too much IOPS<br>
/ bandwith (io starvation, storage link saturation)<br>
- be able to guarantee (minimal) disk IO performance. In combination with "per<br>
user system datastores (ONE 4.4)" you can choose the right disk type<br>
to satisfy latency needs.<br>
<br>
What do you think?<br>
<br>
Gr. Stefan<br>
<br>
P.s. with something like vdc-nebula in place [1], the need to restrict IO<br>
will be much less then in traditional io settings (very cool project<br>
indeed).<br>
<br>
[1]: <a href="http://blog.opennebula.org/?p=5408" target="_blank">http://blog.opennebula.org/?p=5408</a></blockquote><div><br></div><div>That's really interesting, indeed.</div><div>Let's think of how this would look in OpenNebula.</div>
<div><br></div><div>The first and easiest option that comes to mind is to allow a new attribute DISK/RAW, that would look like:</div><div><br></div><div>DISK = [</div><div> IMAGE_ID = 7,</div><div> RAW = "<iotune></div>
<div> <total_bytes_sec>10000000</total_bytes_sec></div><div> <read_iops_sec>400000</read_iops_sec></div><div> <write_iops_sec>100000</write_iops_sec></div><div> </iotune>"</div>
<div>]</div><div><br></div><div>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.</div><div><br></div><div>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].</div>
<div><br></div><div><br></div><div><br></div><div>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:</div>
<div><br></div><div><div><div><VM_QUOTA></div><div> <VM></div><div> <CPU></div><div> <CPU_USED></div><div> <MEMORY></div><div> <MEMORY_USED></div><div> ..</div><div> <TOTAL_BYTES_SEC></div>
<div> </VM></div><div></VM_QUOTA></div></div></div><div><br></div><div>Or if we should think of a more flexible definition of the quotas mechanism. I'm thinking of something like this in oned.conf:<br></div>
<div><br></div><div>VM_QUOTA_DEFINITION = [</div><div> VM_ATTRS = "/VM/DISK/TOTAL_BYTES_SEC /VM/DISK/READ_BYTES_SEC /VM/DISK/WRITE_BYTES_SEC"</div><div> NAME = DISK_IOTUNE</div><div>]</div><div><br></div><div>
But this may be a bit overkill.</div><div><br></div><div><br></div><div><br></div><div>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.</div><div>
<br></div><div>Regards,</div><div>Carlos.</div><div><br></div><div>[1] <a href="http://opennebula.org/documentation:rel4.4:oned_conf#restricted_attributes_configuration">http://opennebula.org/documentation:rel4.4:oned_conf#restricted_attributes_configuration</a></div>
<div>[2] <a href="http://opennebula.org/documentation:rel4.4:oned_conf#inherited_attributes_configuration">http://opennebula.org/documentation:rel4.4:oned_conf#inherited_attributes_configuration</a></div><div>[3] <a href="http://dev.opennebula.org/issues/2530">http://dev.opennebula.org/issues/2530</a></div>
<div>[4] <a href="http://dev.opennebula.org/issues/2530">http://dev.opennebula.org/issues/2530</a><br>--<br>
<div>Carlos Martín, MSc<br>Project Engineer</div><div>OpenNebula - Flexible Enterprise Cloud Made Simple<br><div><span style="border-collapse:collapse;color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px"><a href="http://www.opennebula.org/" target="_blank">www.OpenNebula.org</a> | <a href="mailto:cmartin@opennebula.org" target="_blank">cmartin@opennebula.org</a> | <a href="http://twitter.com/opennebula" target="_blank">@OpenNebula</a></span></div>
</div></div></div></div></div>