The problems with the interim idea is that it will make it difficult/tricky to plan your upgrade when you go to a supported method, and you'll have to have them install something custom of yours on top or alongside of 4.1, since it won't be in the release. In the long run it's probably not great to do a switchup like that.
What it sounds like you want for your interim solution is to only have one volume/vm root on each primary storage pool. The only way I can think of to do this in an automated fashion is with a management utility outside of cloudstack (or perhaps a patched cloudstack UI), so when a user wants to create a volume or vm it looks like this: send createVolume to your web utility w/size and qos settings your web utility talks to your solidfire device, provisions the lun your web utility talks to cloudstack, creates a unique disk offering with unique tag 12345 your web utility talks to cloudstack, registers primary storage pool using newly provisioned lun, with unique tag your web utility sends cloudstack createVolume with newly created disk offering. So instead of the normal 'set up san target/lun' -> 'create primary storage' -> 'create disk offering' -> 'create volume from offering', it looks like 'create volume (to your tool)' -> 'create san target/lun' -> 'create primary storage' -> 'create disk offering' -> 'create volume from offering(in cloudstack)' What might be better is to just utilize what's already there in the meantime, and say "hey, you can utilize our storage to create high performance pools and low performance pools, and the customer can choose which one his vm is a part of, but per-vm iops won't be available until July." On Thu, Feb 7, 2013 at 3:55 PM, Edison Su <[email protected]> wrote: > 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 [mailto:[email protected]] > Sent: Thursday, February 07, 2013 11:18 AM > To: [email protected]; 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 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™
