cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <>
Subject Re: CloudStack Storage Plug-in Framework for 4.2
Date Thu, 21 Mar 2013 02:01:09 GMT
Hi Marcus,

Thanks for that info.

I am not all that familiar with KVM ... at least yet.  :)  I had thought
the way one would utilize an iSCSI target in CS today for KVM was via
Shared Mount Point, but I could certainly be wrong.

What are your thoughts on the other points I was making around the plug-in?
 Was I making sense in general?


On Wed, Mar 20, 2013 at 7:54 PM, Marcus Sorensen <>wrote:

> I'm out of touch on the other technologies, but you probably wouldn't use
> a shared mount point on KVM. You would use the block devices themselves as
> they show up.
> Cluster LVM for KVM, for example, gives cloudstack a pool, where it
> creates virtual block devices, and those are treated like raw disks for the
> VMS to use. I would imagine a SAN storage plugin working nearly the same
> way, just pushing the pool out of the host OS and onto the SAN. Cloudstack
> still creates the volumes (via the plugin), but also does the work of
> connecting the luns to the proper hosts where their VMs will run, using
> them as dedicated block devices.
> Shared mount point would mean that you'd put a cluster filesystem on your
> dedicated lun, mount it, and then create a single flat file on it to
> represent your VM disk.
> On Mar 20, 2013 7:44 PM, "Mike Tutkowski" <>
> wrote:
>> Hi,
>> Some questions have come up recently regarding the 4.2 storage plug-in
>> that Edison implemented.
>> In an attempt to clarify this, I'm sending out this e-mail with my
>> understanding of how the new plug-in framework will operate in 4.2.
>> Hopefully Edison or maybe David Nalley (but anyone else, of course) can
>> comment on if this is accurate.
>> Thanks!
>> * The storage vendor creates a storage plug-in.
>> * Primary Storage can be associated with this plug-in (as opposed to
>> being associated with pre-existing storage).
>> * When a Compute or Disk Offering is executed and it is tagged to use
>> Primary Storage that makes use of this plug-in, the plug-in is invoked to
>> create the necessary storage (let's say an iSCSI volume).
>> * A datastore (for VMware) or a storage repository (for XenServer) then
>> needs to be created for the SAN volume to be utilized from CS.  I suppose a
>> shared mount point would need to be created for KVM.
>> * The VM or data disk is placed on the datastore or storage repository
>> and it (the VM or data disk) is the only object that ever utilizes this
>> datastore or storage repository (or shared mount point, for KVM).
>> The idea behind this being that storage does not have to be set aside
>> ahead of time in bulk and that you can map a single VM (or data disk) to a
>> single, say, SAN volume.
>> --
>> *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