Exactly...and Edison's new plug-in architecture will enable us to create a volume per VM Instance or Data Disk, but that won't be out until 4.2.
In the meanwhile, I'm kind of brainstorming to see if I can write a script to enable this functionality before 4.2 (and for customers who won't upgrade to 4.2 right away when it comes out). On Thu, Feb 7, 2013 at 2:27 PM, Ahmad Emneina <aemne...@gmail.com> wrote: > 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> >> *™* >> > > -- *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> *™*
