I know you asked Edison, but I'll chime in and he can confirm/reject. Primary storage will define where your storage is and how to connect. These are up to the developer to decide on, and really come down to what it takes to identify/configure the device
management IP address target address/IQN disk pool (in case you intend for an admin to have multiple pools of disks to choose from, for example) storage tags Then disk offerings specify properties. The main property right now is size, along with the tag to select a primary storage. Disk size, disk iops disk bandwidth storage tags So the architecture that an admin could create might look like this: SAN device san0.domain.com: API listens on a gigabit management network, 192.168.50.10 iscsi Target exists on a 10Gbit SAN network, 10.10.10.10 has pool0 which consists of 8 x SSD in RAID10, created lun 0 and exported as target pas pool1 which consists of 12 x HDD in RAID60, created lun 1 and exported as target Admin goes into CloudStack, registers primary storage. Fills out the following: Name: san0-ssd Management IP: 192.168.50.10 Target: 10.10.10.10 LUN: 0 Tags: fast Admin goes into CloudStack, registers primary storage. Fills out the following: Name: san0-hdd Management IP: 192.168.50.10 Target: 10.10.10.10 LUN: 1 Tags: slow Admin creates disk offering: Name: high-ssd Size: custom Tags: fast iops: 1000 bandwidth(MB): 100Admin creates disk offering: Size: custom Tags: fast iops: 1000 bandwidth(MB): 100 Admin creates disk offering: Name: medium-ssd Size: custom Tags: fast iops: 500 bandwidth(MB): 50 Admin creates disk offering: Name: 100GB-hdd Size(GB): 100 Tags: slow iops: 100 bandwidth(MB): 25 Now, users create disks by selecting a disk offering and filling in any options that are 'custom'. On Wed, Feb 6, 2013 at 9:16 PM, Mike Tutkowski <[email protected]> wrote: > Hi Edison, > > I have another quick question for you. :) > > So, my first priority at SolidFire is to get a CloudStack storage plug-in > up and running. > > Once that is complete, I need to look into how to enable CloudStack users > to make use of our hard quality of service (QoS) feature. This is the > feature where a user can associate a max and min number of IOPS to a given > volume (LUN). > > You and I have discussed this a bit, but I was wondering if you could give > me an idea of where you see admins or users specifying such values. Our > preference is to have the admin who creates a Primary Storage type based on > the SolidFire plug-in specify theses values. Then a user could make use of > Compute and/or Disk Offerings that leverage the settings that were > configured when the Primary Storage type was created. > > Is that how you were envisioning this would work? > > Also, we could foresee there being several "levels" of volumes supported by > the SolidFire plug-in. For example, volumes created with "normal" IOPS and > those created with higher IOPS. > > How do you picture this would fit into your new architecture? In other > words, how would one associate a Compute or Disk Offering that is based on > one SolidFire quality of service versus another. > > Thanks! > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: [email protected] > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *™*
