cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <>
Subject Re: Supporting SolidFire QoS Before 4.2
Date Thu, 07 Feb 2013 21:21:47 GMT
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.  :)


On Thu, Feb 7, 2013 at 1:02 PM, Ahmad Emneina <> 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 <
>> 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:
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud<>
>> *™*

*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
o: 303.746.7302
Advancing the way the world uses the

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message