Sounds good - let's plan on that for 4.5. :)
On Thu, Mar 6, 2014 at 10:15 PM, Punith S <punit...@cloudbyte.com> wrote: > yea sure , will target this for 4.5. > > thanks > > > On Thu, Mar 6, 2014 at 8:37 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com > > wrote: > > > Just to clarify, Punith: You are correct that changing storage QoS > > dynamically will be a more time-consuming task than adding that kind of > > support on the hypervisor side. That's why I say with the Feature Freeze > > date as it is for 4.4 that we should look to address this in 4.5. > > > > Thanks > > > > > > On Thu, Mar 6, 2014 at 3:42 AM, Wido den Hollander <w...@widodh.nl> > wrote: > > > > > > > > > > > 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)* > > >>>> > > >>> > > > > > > -- > > *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)* > > > > > > -- > 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)*
