incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <>
Subject RE: Supporting SolidFire QoS Before 4.2
Date Thu, 07 Feb 2013 22:55:30 GMT
Another solution would be, totally bypass cloudstack and hypervisor, create LUN in your storage
box, then give the IQN to guest VM. Inside guest VM, there may have a script, which can grab
that IQN from somewhere(can be in user data), then scan iSCSI, mount the device, etc. It can
work with all the hypervisors.

From: Mike Tutkowski []
Sent: Thursday, February 07, 2013 11:18 AM
To:; Edison Su; Marcus Sorensen
Subject: Supporting SolidFire QoS Before 4.2

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

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


Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
o: 303.746.7302
Advancing the way the world uses the cloud<>(tm)

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