incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <>
Subject Supporting SolidFire QoS Before 4.2
Date Thu, 07 Feb 2013 19:17:40 GMT
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"


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)).


*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