cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject Re: CloudStack Storage Plug-in Framework for 4.2
Date Thu, 21 Mar 2013 02:08:13 GMT
Yes, you can utilize an iscsi lun as shared mount point. Create a lun, make
sure your hosts can see it, create a cluster filesystem on it, mount it on
all hosts, then tell cloudstack about it so it can start creating VM disk
images on it. But if you're talking about a 1:1 mapping of lun to VM disk,
and doing it via plugin, you'll probably want to bypass the unnecessary
cluster fs layer and just use the disks directly.

On Mar 20, 2013 8:01 PM, "Mike Tutkowski" <>
> 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?
> Thanks!!
> On Wed, Mar 20, 2013 at 7:54 PM, Marcus Sorensen <>
>> 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" <>
>>> 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.
> e:
> o: 303.746.7302
> Advancing the way the world uses the cloud™

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