My $0.02 is $solidfiredev should focus on the end goal of implementing this awesome feature, and not some interim solution that wont be supported going forward.
On Thu, Feb 7, 2013 at 2:06 PM, Mike Tutkowski <[email protected] > wrote: > So, yeah, at this point, I'm playing around with ideas. I'm thinking my > initial flow, while not perfect by any means (reference potential race > condition), might work sufficiently. > > I definitely would like to tap people in the CloudStack community for a > sanity check, though. :) > > > On Thu, Feb 7, 2013 at 2:30 PM, Mike Tutkowski < > [email protected]> wrote: > >> 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 <[email protected]> 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 <[email protected]>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 < >>>>>> [email protected]> 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: [email protected] >>>>>>> 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: [email protected] >>>>> 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: [email protected] >>>> 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: [email protected] >> 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: [email protected] > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *™* >
