Hmm, you could do something like create a 'high iops' storage pool, and the VM host mounts that and creates multiple vm volumes (vhd) on that, just like stock, but then you have a script that polls cloudstack occasionally, asks how many volumes are on that pool, and adjusts your LUN's iops to be volumes x iops. So if you register a high perf 10TB lun to provide Z iops per volume as a primary storage, then create 3 volumes on it, your script sets the iops on that lun to Z x 3. It's still limited by only offering certain classes of performance, instead of a large variety (one class per primary pool), but it's another avenue to consider.
On Thu, Feb 7, 2013 at 4:28 PM, Marcus Sorensen <[email protected]> wrote: > He's saying that the VM can connect via iscsi directly to the > solidfire device, rather than the host. You'd lose more performance > that way and there's more overhead, but it would be a way to give > individual VMs their own solidfire LUN. > > On Thu, Feb 7, 2013 at 4:06 PM, Mike Tutkowski > <[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]> 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™ >> >> >> >> >> -- >> Mike Tutkowski >> Senior CloudStack Developer, SolidFire Inc. >> e: [email protected] >> o: 303.746.7302 >> Advancing the way the world uses the cloud™
