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)
