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.
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)*
