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
