Exactly...and that shouldn't be too much of a problem. The "trick" will come into play when we have to take into consideration "generic" storage properties and that Min and Max IOPS should really be part of this group.
On Wed, Mar 5, 2014 at 11:59 AM, Marcus <shadow...@gmail.com> wrote: > Yes, that's what I mean. When the offering is changed, we need to have > a hook in there that calls the applicable storage driver for the > volume. Then the drivers can be free to implement or not implement. > > On Wed, Mar 5, 2014 at 11:36 AM, Mike Tutkowski > <mike.tutkow...@solidfire.com> wrote: > > Hi Marcus, > > > > In 4.4 I'm adding the ability to allow admins to specify Min and Max IOPS > > for Compute Offerings, as well (support only for XenServer in 4.4). > > > > I agree changing of IOPS should be doable through changing a Disk or > Compute > > Offering, but this doesn't work right now as the storage framework > doesn't > > tell the plug-in in question about the change. > > > > This is part of what Punith should investigate as we move forward with > this > > in 4.5. > > > > Talk to you later, > > Mike > > > > > > 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(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)*
