cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <>
Subject Re:
Date Wed, 13 Nov 2013 20:33:51 GMT
Just as an FYI (to whom it may concern):

For me, personally, my primary focus has been (and continues to be) on
bringing true storage Quality of Service (QoS) to CloudStack (guaranteed
IOPS on a per-CloudStack-volume basis).

Prior to 4.2, CloudStack expected an admin to preallocate large amounts of
storage (ex. a large volume on a SAN), then introduce this storage to his
hypervisor, then create Primary Storage in CloudStack to represent that
hypervisor-configured storage. At this point, a user could then create root
and data disks that leveraged this storage (i.e. multiple root and data
disks running on the same storage volume).

That model may be efficient in terms of, say, number of iSCSI connections,
but it is not very useful from the point of view of a storage system that
is designed to deliver true QoS (eliminating the Noisy Neighbor effect by
guaranteeing IOPS on a per-volume basis).

In such a storage system, each volume on the SAN has independent QoS

In this world, it is ideal to map a single CloudStack volume to a single
volume on the SAN. This means being able to create volumes on the SAN
dynamically (ex. when a CloudStack volume is attached to a VM for the first

Much of what Edison Su worked on for 4.2's storage-framework changes
enabled me to take a large first step in that I could create a plug-in that
could dynamically create volumes on our SAN (SolidFire SAN). However, the
concept of preallocated storage is so embedded in CloudStack that I've
needed to update core components of CloudStack, as well as CloudStack
hypervisor-related code, to deal with dynamically created volumes.

In 4.2 I released support for storage QoS with data disks on XenServer and

In 4.3 I am releasing support for storage Qos with data disks on KVM.

As we move forward, I plan to support storage QoS with root volumes on
these hypervisors, as well (most likely starting with XenServer).

It has been a bit tricky to support hypervisor snapshots in this model
(where volumes are created dynamically on a SAN and the hypervisor data
structures like SRs or datastores are created behind the scenes). This is
another area I'm tackling for the 4.3 release (for XenServer and VMware).

On Wed, Nov 13, 2013 at 11:50 AM, Steve Wilson <>wrote:

> Hi Daan, Prasanna, Simon, David and Andrei!
> Thanks for chiming in.  Great way to kick off the discussion.
> In my thinking, we might want to look at things in three buckets:
> 1. Things that could go into a maintenance release like a 4.2.x
> 2. Things that could go into a minor release like a 4.4
> 3. Things that would require major architecture changes and might wind up
> in 5.0 or something like it
> From a Citrix perspective, we're definitely looking at things that fall
> into all three of these buckets.  We've contributed a huge number of fixes
> to 4.2.1 and a number of features to 4.3.  We're also now starting to plan
> our contributions to 4.4 as well.  However, since I joined the community,
> I've seen very little discussion of what's really next.  What are the
> major things we'd like to see done?  I don¹t have a particular timeframe
> in mind for these things, I'm just looking to spark discussion --
> especially as we go to Collab next week.
> Things that are interesting to me that fit in bucket three.  Here are a
> couple:
> What level of scale should CloudStack be able to support?  I imagine we'll
> bee CloudStack clouds managing millions of VMs in the next few years.
> What do we need to do to make that effective?
> I think people will want to manage "micro-clouds" -- very small, but
> flexible clouds for special purpose needs.  What would CloudStack need to
> do to scale down very small and still be cost effective to run?
> Any thoughts about these, or any other ideas?
> -Steve
> On 11/12/13 9:58 PM, "Daan Hoogland" <> wrote:
> >I don't see any sugestions I don't like (including not breaking api) but,
> >
> >- I like to second Simnons 'HA for VPC routers'
> >extra. It is hurting not having that.
> >
> >- smaller releases is another one. monthly preferably or maybe an db
> >upgrade model that allows for running snapshots and upgrading them
> >regularly. The time to market for new features is now between 4 and 8
> >months:(
> >
> >- related: master as a stable/always building and passing unit tests
> >
> >On Wed, Nov 13, 2013 at 6:39 AM, Prasanna Santhanam <>
> >wrote:
> >> On Tue, Nov 12, 2013 at 11:41:17PM +0000, Steve Wilson wrote:
> >>> Hi All,
> >>>
> >>> As we ramp towards freeze on 4.3 and start talking about 4.4, I
> >>> thought it would be fun to queue up a discussion here on the list
> >>> before Collab next week.
> >>>
> >>> What do you envision in the next MAJOR release of CloudStack?  Call
> >>> it 5.0 or whatever you like, but what would you like to see there?
> >>> What would you change?  What would you enhance?  Are there big bets
> >>> we should be placing as a community?
> >>>
> >>> Feel free to post any thoughts here and I'll look forward to talking
> >>> to many of you in person at Collab next week.  You are coming to
> >>> Collab, right?
> >>>
> >>
> >> simplified upgradeability at all stages of development from version x
> >> to version y.
> >>
> >> --
> >> Prasanna.,
> >>
> >> ------------------------
> >> Powered by
> >>

*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
o: 303.746.7302
Advancing the way the world uses the

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message