More to your example, there is no cloudstack controlled iops or performance setting concerning storage (yet), but what an admin could possibly do is define a primary storage that is 'regular performance', tag it something, like 'lowperf', then define a primary storage that is high performance, tag it 'highperf', then set it up such that root volumes get carved out of 'lowperf' (by setting up the storage tag on the compute offering that will be used to deploy VMs to 'lowperf') and then create a disk offering with a tag matching 'highperf', where customers could acquire extra data volumes for their VMs that are higher performing for database use or whatnot. You can do lots of thing with the tags.
So if it's possible for your customers to do something like create a lun, set it's performance, and then import it as a storage pool, then this would work. I think the better long term solution however would be for cloudstack to be able to have some sort of iops/throughput settings in the disk offering, and then apply those per data disk, per VM, similar to the network bandwidth, cpu mhz, and other resources. On Jan 13, 2013 8:56 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> wrote: > Another thing I was curious about (and perhaps someone on this list can > answer) is if, say, Xen is running one VM from one virtual volume (equal to > a LUN, in this scenario), can an app running in this VM access a data > volume from a different virtual volume? > > So, the VM is running off of one virtual volume and the VM has access to > another virtual volume that one of its apps is using? > > Does CloudStack support this model? > > What this question comes down to is my company, SolidFire, offers a > sophisticated feature called hard quality of service. One a > volume-by-volume basis (which we think of as being equal to a LUN), you > "dial in" the performance (IOPS) you need for the volume in question (not > "high, medium, and low," but the actual max and min IOPS). > > I'm under the impression CloudStack is not exactly geared up at the moment > to support such a model. Is that a true assessment? > > Thanks! > > > On Sun, Jan 13, 2013 at 11:02 AM, Sebastien Goasguen <run...@gmail.com > >wrote: > > > > > On Jan 13, 2013, at 6:56 PM, Wido den Hollander <w...@widodh.nl> wrote: > > > > > > > > > > > On 01/13/2013 06:47 PM, Sebastien Goasguen wrote: > > >> > > >> On Jan 11, 2013, at 9:22 PM, Marcus Sorensen <shadow...@gmail.com> > > wrote: > > >> > > >>> On the KVM side, you can do NFS, Local disk storage, CLVM (shared > block > > >>> device that has Clustered LVM on top of it, a primary pool is a > > particular > > >>> volume group and cloudstack carves out logical volumes out of it as > > >>> needed), and RBD (RADOS Block devices, Ceph shared storage. You point > > it at > > >>> your cluster and cloudstack creates RBD devices as needed). Also > > >>> SharedMountPoint for something like GFS,OCFS or some shared > filesystem. > > >>> > > >>> Xen has NFS, a 'PreSetup' where you create an SR in your Xen cluster > > and > > >>> pass the SR to it (I think), and iSCSI (I'm not clear on how this > > works, > > >>> but I'm sure its in the docs) > > >> > > >> Hi Marcus, that's a nice summary. > > >> > > >> Can't we do any of the distributed file systems for primary storage > > with Xen ? > > >> > > > > > > I've been trying to convince the people from Xen to implement RBD into > > the blktap driver, but that hasn't been done. > > > > > > The people from Ceph also have had some conversations with Citrix, but > > so far nothing has come out of it. > > > > > > KVM seems to be the winner here if it comes down to distributed storage > > since it's open source and stuff can be implemented very quickly. > > > > > > If we want to get this into Xen, it's up to Citrix to implement it. > They > > just might need a little extra push. > > > > > > If Citrix gets RBD into blktap, I'll make sure CloudStack knows how to > > work with it :) > > > > I will ping some of the xen open source developers I know. > > > > Any of you guys know of a good presentation on cloudstack storage > support ? > > > > We have lots of things like caringo, swift, gluster etc…that don't seem > to > > be very well documented. Is there an exhaustive list and some > documentation > > somewhere ? > > > > thanks > > > > > > > > > > Wido > > > > > >> -Sebastien > > >> > > >>> > > >>> On Fri, Jan 11, 2013 at 1:14 PM, Mike Tutkowski < > > >>> mike.tutkow...@solidfire.com> wrote: > > >>> > > >>>> So, being new to CloudStack, I'm not sure what kind of storage > > protocols > > >>>> are currently supported in the product. To my knowledge, NFS shares > > are > > >>>> what CloudStack has only supported in the past. Does CloudStack > > support > > >>>> iSCSI targets at present? > > >>>> > > >>>> Thanks! > > >>>> > > >>>> > > >>>> On Thu, Jan 10, 2013 at 3:58 PM, Mike Tutkowski < > > >>>> mike.tutkow...@solidfire.com> wrote: > > >>>> > > >>>>> Thanks, Edison! > > >>>>> > > >>>>> That's very helpful info. > > >>>>> > > >>>>> > > >>>>> On Thu, Jan 10, 2013 at 3:49 PM, Edison Su <edison...@citrix.com> > > wrote: > > >>>>> > > >>>>>> > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > > >>>>>>> Sent: Thursday, January 10, 2013 2:22 PM > > >>>>>>> To: cloudstack-dev@incubator.apache.org > > >>>>>>> Subject: CloudStack Storage Question > > >>>>>>> > > >>>>>>> Hi everyone, > > >>>>>>> > > >>>>>>> I'm new to CloudStack and am trying to understand how it works > with > > >>>>>>> regards to storage exposed to hypervisors. > > >>>>>>> > > >>>>>>> For example: > > >>>>>>> > > >>>>>>> My company, SolidFire, has a feature that exists at the > > virtual-volume > > >>>>>> (for us, > > >>>>>>> equivalent to a LUN) layer: Hard Quality of Service. So, for > each > > >>>>>> volume in > > >>>>>>> one of our clusters, you can specify a minimum and maximum number > > of > > >>>>>>> IOPS (beneficial to Cloud Service Providers who want to write > hard > > >>>> SLAs > > >>>>>>> around performance). > > >>>>>>> > > >>>>>>> We have a potential customer who is using CloudStack currently > with > > >>>>>> another > > >>>>>>> vendor (via NFS shares). They asked me today how a hypervisor > run > > >>>> under > > >>>>>>> CloudStack would see the iSCSI storage exposed to them in one of > > our > > >>>>>>> volumes. More specifically, can the hypervisor see a volume per > > VM or > > >>>>>> is the > > >>>>>>> hypervisor forced to create all of its VMs off of the same > volume? > > If > > >>>>>> the > > >>>>>>> hypervisor is forced to create all of its VMs off of the same > > volume, > > >>>>>> then this > > >>>>>>> would significantly reduce the value of our hard quality of > service > > >>>>>> offering > > >>>>>>> since all of these VMs would have to run at the same performance > > SLA. > > >>>>>> > > >>>>>> > > >>>>>> It depends on hypervisor, for KVM, per VM per LUN will work, > > xenserver > > >>>>>> doesn't work. For Vmware, it will work, but with a limitation(one > > ESXi > > >>>> host > > >>>>>> can only have 256 LUN at max). > > >>>>>> > > >>>>>>> > > >>>>>>> Can anyone help me better understand how this would work? > > >>>>>>> > > >>>>>>> Thanks so much!! > > >>>>>>> > > >>>>>>> -- > > >>>>>>> *Mike Tutkowski* > > >>>>>>> *Senior CloudStack Developer, SolidFire Inc.* > > >>>>>>> e: mike.tutkow...@solidfire.com > > >>>>>>> o: 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: mike.tutkow...@solidfire.com > > >>>>> o: 303.746.7302 > > >>>>> Advancing the way the world uses the cloud< > > >>>> http://solidfire.com/solution/overview/?video=play> > > >>>>> *™* > > >>>>> > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> *Mike Tutkowski* > > >>>> *Senior CloudStack Developer, SolidFire Inc.* > > >>>> e: mike.tutkow...@solidfire.com > > >>>> o: 303.746.7302 > > >>>> Advancing the way the world uses the > > >>>> cloud<http://solidfire.com/solution/overview/?video=play> > > >>>> *™* > > >>>> > > >> > > > > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *™* >
