got it. the iops are shared amongst guest vm disks that reside on a volume. So is the idea to create a volume per vm?
On Thu, Feb 7, 2013 at 1:22 PM, Mike Tutkowski <mike.tutkow...@solidfire.com > wrote: > Also, when I say "volume", that is equal to "LUN" when talking about > SolidFire. > > > On Thu, Feb 7, 2013 at 2:21 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> Hi Ahmad, >> >> Thanks for the comments. >> >> In regards to your first idea about creating multiple targets on the >> SolidFire system, I'd be concerned that I wouldn't know how many to create. >> Would I make 100...200...? Not sure. Since SolidFire can control IOPS on >> a per-volume basis, in our ideal world, each VM Instance or Data Disk would >> be serviced by a single SolidFire volume. If I ever have more than one VM >> Instance, for example, running on the same SolidFire volume, I can't >> guarantee any individual VM its IOPS (as its IOPS may be absorbed unequally >> by the other VM(s) running on the same volume). >> >> Does that make sense? If you see some flaw in my logic, please let me >> know. :) >> >> Thanks! >> >> >> On Thu, Feb 7, 2013 at 1:02 PM, Ahmad Emneina <aemne...@gmail.com> wrote: >> >>> Hey Mike, >>> >>> The cleanest approach as a user would be: >>> I create multiple targets on the solid fire. Each with a different IOPs >>> setting (assuming you can control max iops for volumes this way). I'd mount >>> each to the hypervisor and create a specific service offering for each. >>> That way youre intercepting calls with a script and modifying >>> tags/offerings on the fly, and avoid said race condition. >>> >>> second cleanest approach IMO: >>> Or to backpack off your previous method. Create 3 different service >>> offerings (fast, medium, slow). That way when the deploy vm is called, >>> your volume create script can intercept the call and will know the QOS >>> based on the offering. >>> >>> Why I'd do this is say you change the service offering to fast while >>> provisioning a vm, and a user with a disk thats meant to be slow reboots >>> her vm... she'll be upgraded to fast. All because your modifying the one >>> and only offering. >>> >>> >>> On Thu, Feb 7, 2013 at 11:17 AM, Mike Tutkowski < >>> mike.tutkow...@solidfire.com> wrote: >>> >>>> Hi everyone, >>>> >>>> I learned yesterday that Edison's new storage plug-in architecture will >>>> first be released with 4.2. >>>> >>>> As such, I began to wonder if there was any way outside of CloudStack >>>> that >>>> I could support CloudStack users who want to make use of SolidFire's QoS >>>> feature (controlling IOPS). >>>> >>>> A couple of us brainstormed for a bit and this is what we came up with. >>>> Can anyone confirm if this could work? >>>> >>>> ******************** >>>> >>>> The CloudStack Admin creates a Primary Storage that is of the type >>>> PreSetup. This is tagged with a name like "SolidFire_High" (for >>>> SolidFire >>>> High IOPS). >>>> >>>> The CloudStack Admin creates a Compute Offering that refers to the >>>> "SolidFire_High" Storage Tag. >>>> >>>> In the CSP's own GUI, a user picks the Compute Offering referred to >>>> above. >>>> The CSP's code sees the Storage Tag "SolidFire_High" and that cues it >>>> to >>>> invoke a script of mine. >>>> >>>> My script is passed in the necessary information. It creates a >>>> SolidFire >>>> volume with the necessary attributes and hooks it up to the hypervisor >>>> running in the Cluster. It updates my Primary Storage's Tag with the >>>> IQN >>>> (or some unique identifier), then it updates my Compute Offering's >>>> Storage >>>> Tag with this same value. >>>> >>>> Once the Primary Storage and the Compute Offering have been updated, >>>> CloudStack can begin the process of creating a VM Instance. >>>> >>>> Once the VM Instance is up and running, the CSP's GUI could set the >>>> Primary >>>> Storage's and Compute Offering's Storage Tags back to the >>>> "SolidFire_High" >>>> value. >>>> >>>> ******************** >>>> >>>> The one problem I see with this is that you would have to be sure not to >>>> kick off the process of creating such a Compute Offering until your >>>> previous such Compute Offering was finished (because there is a race >>>> condition while the Storage Tag field points to the IQN (or some other >>>> unique identifier)). >>>> >>>> Thanks! >>>> >>>> -- >>>> *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> >>>> *™* >>>> >>> >>> >> >> >> -- >> *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> >> *™* >> > > > > -- > *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> > *™* >
