incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <>
Subject Re: Storage Refactor Question
Date Tue, 05 Feb 2013 22:01:02 GMT
Thanks, Marcus

I'm working on a plug-in right now (for SolidFire).  I've been following
some sample code and looking at

I haven't gotten anything up and running yet, but I was curious what to
expect when the time came.

It sounds like existing behavior will remain in place (regarding Primary
Storage types).  So, when a user wants to create a Compute or Disk Offering
based on storage provided by my plug-in, how does the admin set things up
so that works?  Right now, the admin would use a Storage Tag to reference
one or more Primary Storage types.  Do you know how the admin will create
the association with storage provided by my plug-in?


On Tue, Feb 5, 2013 at 2:51 PM, Marcus Sorensen <> wrote:

> The flow should be identical from a user's point of view. The
> implementation depends on the primary storage. For example, the
> existing methods/primary storage types will continue to work the same,
> no change from a user's perspective, except for more storage options
> as plugins are created.
> What changes in the code is that instead of passing a CreateCommand to
> the VM host to create a qcow2 file, a vhd, a logical volume, or
> whatever constitutes a 'disk' per your primary storage implementation,
> it talks to a new Volume Service that calls your primary storage
> handler. It may do the same thing it did before (in the case of
> existing storage types), or it may go carve out a LUN on the SAN, or
> whatever you define.  This cleans up some of the issues around
> if..elseif...elseif...elseif for every storage type.
> You can certainly implement yet another primary storage type in the
> current code. Then when the refactor comes along you can fix it up,
> but either way the flow will be the same from the user.
> On Tue, Feb 5, 2013 at 1:57 PM, Mike Tutkowski
> <> wrote:
> > Hi everyone,
> >
> > Edison has been working on enhancing CloudStack's storage component for
> > some time now.
> >
> > One of the improvements is to no longer require large amounts of storage
> to
> > be provisioned upfront.  It's my understanding that with his changes you
> > can dynamically create a storage volume (a single LUN) to run a VM on or
> to
> > serve as a data disk.
> >
> > My question is how this works from a user's point of view.  Does anyone
> > have any insight into this?
> >
> > For example, today the admin creates a Primary Storage type ahead of the
> > user needing to use it.  The admin then associates it with a Compute
> and/or
> > a Disk Offering.  The user later elects to make use of a given Compute
> > and/or Disk Offering.
> >
> > I'm curious how the flow will be with storage being dynamically allocated
> > when a user needs it.
> >
> > Thanks!
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e:
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud<>
> > *™*

*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