It ends up with per LUN per primary storage per volume? And do you need to change UI code , in order to invoke your program? If it's only for data disk, your solution will work. May have problem with root disk for system VMs, as they are not created by from UI.
From: Mike Tutkowski [mailto:[email protected]] Sent: Thursday, February 07, 2013 3:14 PM To: Edison Su Cc: [email protected]; Marcus Sorensen Subject: Re: Supporting SolidFire QoS Before 4.2 The logic might be something like this: User picks a Compute Offering with storage tag "SolidFire". CSP's GUI sees that the Storage Tag is "SolidFire" and this cues it to invoke my program and pass it in the necessary data. My program creates a SolidFire volume and talks to the hypervisor to make it aware of this volume (for XenServer, this would entail creating a storage repository that is based on my iSCSI volume). My program could make a CS API call to update a known Primary Storage (maybe it has a known name like "SolidFirePrimaryStorage"). This program would update its Storage Tag to, say, the IQN of the volume that was just created. This program would then go and update the Compute Offering that was selected to have its Storage Tag equal to that IQN. Once these changes are in place, the CSP's GUI can initiate the process of spinning up a VM based on our Compute Offering and Primary Storage. When that VM is up and running, the CSP's GUI can restore the Storage Tag "SolidFire" to the Primary Storage and Compute Offerings and we're in our initial state again and ready to service another request (we cannot service another request until the one before it is done). Comments? I know it's not ideal, but we're mainly looking for something workable at this point. :) On Thu, Feb 7, 2013 at 4:06 PM, Mike Tutkowski <[email protected]<mailto:[email protected]>> wrote: Hi Edison, I'm not sure I entirely follow. Creating the volume (LUN) on our SAN is straightforward enough. We'd get back an IQN. Are you saying at this point I'd talk to, say, XenServer and have it create a storage repository that makes use of the iSCSI target (my IQN)? If so, once that is done, I was thinking I'd update a known (PreSetup-based) Primary Storage's Storage Tag. After, I'd update the single Compute Offering that references that Primary Storage by changing its Storage Tag to be equal to that of my Primary Storage. Once this is done, the VM could be spun up from the Compute Offering (and underlying Primary Storage). When the VM Instance is up and running, the Compute Offering's and Primary Storage's Storage Tag could be changed back to some expected value. I don't particularly like this solution in the sense that you can't kick off such a new Compute Offering until the one before it was done, but it would only serve as a temporary measure to help customers leverage our QoS feature. What do you think? Does this sound doable with the CS API? On Thu, Feb 7, 2013 at 3:55 PM, Edison Su <[email protected]<mailto:[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]<mailto:[email protected]>] Sent: Thursday, February 07, 2013 11:18 AM To: [email protected]<mailto:[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]<mailto:[email protected]> o: 303.746.7302<tel:303.746.7302> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm) -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: [email protected]<mailto:[email protected]> o: 303.746.7302<tel:303.746.7302> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm) -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: [email protected]<mailto:[email protected]> o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm)
