awesome! Can you implement cpu tuning or network QoS as well ? Thanks!
-Wei 2014-03-06 11:42 GMT+01:00 Wido den Hollander <w...@widodh.nl>: > > > On 03/05/2014 07:18 PM, Marcus wrote: > >> For the hypervisor version of throttling, we just need >> ResizeVolumeCommand to pass the VolumeObjectTO rather than just the >> volume uuid/path, so that when we change offerings on the agent side >> we have the info we need to update libvirt with the new iops/bytes >> settings. We also need the libvirt java bindings to do so, per >> previous discussion. >> >> > I'm already working on the patch: https://github.com/wido/ > libvirt-java/tree/change-iops > > It's not so hard to implement it seems. Hopefully I'll have it ready after > the weekend. > > > On Wed, Mar 5, 2014 at 11:12 AM, Marcus <shadow...@gmail.com> wrote: >> >>> Wouldn't this be implemented as just changing disk offerings? The >>> resizeVolume API call already allows you to switch disk offerings, we >>> just need to add a hook in there to optionally call the storage driver >>> (If volume is deployed to a primary storage) to make an update to the >>> iops properties on the backend storage. Come to think of it, depending >>> on how storage drivers are implementing the iops/limits feature, >>> resizeVolume might be breaking this, or simply requiring a reboot to >>> apply. That is, if the storage driver is setting the iops just once >>> upon volume creation, it's probably breaking when a user moves a disk >>> between offerings that may have alternate iops limits (this is >>> probably not the case for hypervisor throttling, as that's applied >>> from whatever is current when the VM starts up). >>> >>> On Wed, Mar 5, 2014 at 9:58 AM, Mike Tutkowski >>> <mike.tutkow...@solidfire.com> wrote: >>> >>>> Hi, >>>> >>>> Perhaps I'm not following this correctly, but I'm a bit lost on why we >>>> are >>>> talking about changing settings on running VMs. >>>> >>>> From what I understand, you are a representative of a storage vendor >>>> that >>>> has a rate-limiting feature. You want to be able to not only set the Max >>>> IOPS, but also adjust them. Is this true? >>>> >>>> If so, I totally agree. SolidFire has control over Min and Max IOPS and >>>> it >>>> is on my to-do list to add support into CloudStack to be able to >>>> dynamically change these values (right now customers do this from the >>>> SolidFire API or its GUI). >>>> >>>> If you would like to work on this feature, that would be great. I'd be >>>> happy to review your design and code. >>>> >>>> One complication is that we are looking at adding support for generic >>>> key/value pairs for storage plug-ins in 4.5 and this would effectively >>>> remove the need to have Min and Max IOPS as "special" fields in the >>>> CloudStack API and GUI. >>>> >>>> I'm going to CC Chris Suichll (from NetApp) as he and I have already >>>> discussed this generic-properties concept. It would be good to get his >>>> feedback on how we might go about dynamically updating storage-plug-in >>>> key/value pairs. >>>> >>>> Thanks! >>>> Mike >>>> >>>> >>>> On Wed, Mar 5, 2014 at 3:12 AM, Wido den Hollander <w...@widodh.nl> >>>> wrote: >>>> >>>> >>>>> >>>>> On 03/05/2014 10:12 AM, Wei ZHOU wrote: >>>>> >>>>> I was thinking about it last week. >>>>>> AFAIK, libvirt-java 0.5.1 does not support change setting on running >>>>>> vms, >>>>>> but virsh command line and libvirt API supports it. >>>>>> so the sulution are >>>>>> (1) change libvirt-java to support it, and make it released in the >>>>>> next >>>>>> version. Maybe Wido can help us. >>>>>> >>>>>> >>>>> Sure! That seems the best way forward. What is currently lacking in the >>>>> libvirt-java bindings? >>>>> >>>>> >>>>> (2) call virsh command line. >>>>> >>>>>> >>>>>> >>>>>> Please, please, do not do that. That's very hacky. We should really >>>>> keep >>>>> using the libvirt-java bindings and stay away from invoking binaries. >>>>> >>>>> Wido >>>>> >>>>> >>>>> -Wei >>>>> >>>>>> >>>>>> 2014-03-05 9:01 GMT+01:00 Punith S <punit...@cloudbyte.com>: >>>>>> >>>>>> hi guys, >>>>>> >>>>>>> >>>>>>> we are having a fixed max iops for each volume being attached to the >>>>>>> instance in managed storage, >>>>>>> so this a problem where we are making users to pre allocate the iops >>>>>>> of >>>>>>> the >>>>>>> disk without having an option to change or resize it, similar to the >>>>>>> size >>>>>>> metric. >>>>>>> >>>>>>> so i would like to introduce a new feature which enables to change or >>>>>>> resize the volume iops on fly without detaching the datadisk of the >>>>>>> VM >>>>>>> with >>>>>>> zero downtime where performance of the datadisk can be altered at any >>>>>>> point >>>>>>> with the available iops of the primary storage pool, which is >>>>>>> similar in >>>>>>> resizing the volume or datadisk of the vm , where in latter we have >>>>>>> to >>>>>>> detach the datadisk. >>>>>>> >>>>>>> what do you guys think about this feature ? any feedback ? >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> -- >>>>>>> regards, >>>>>>> >>>>>>> punith s >>>>>>> cloudbyte.com >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> -- >>>> *Mike Tutkowski* >>>> *Senior CloudStack Developer, SolidFire Inc.* >>>> e: mike.tutkow...@solidfire.com >>>> o: 303.746.7302 >>>> Advancing the way the world uses the >>>> cloud<http://solidfire.com/solution/overview/?video=play> >>>> *(tm)* >>>> >>>
