Hi Stefan, On Sun, Nov 17, 2013 at 9:46 PM, Stefan Kooman <ste...@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/> | cmar...@opennebula.org | @OpenNebula <http://twitter.com/opennebula>
_______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org