incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: CloudStack Storage Plug-in Framework for 4.2
Date Thu, 21 Mar 2013 02:11:41 GMT
Hey Marcus,

How do you see this plug-in working with VMware?


On Wed, Mar 20, 2013 at 8:11 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> I see...cool - thanks, Marcus!
>
>
> On Wed, Mar 20, 2013 at 8:08 PM, Marcus Sorensen <shadowsor@gmail.com>wrote:
>
>> 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" <mike.tutkowski@solidfire.com>
>> wrote:
>> >
>> > 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 <shadowsor@gmail.com>
>> 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" <
>> mike.tutkowski@solidfire.com> 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: mike.tutkowski@solidfire.com
>> >>> o: 303.746.7302
>> >>> Advancing the way the world uses the cloud™
>> >
>> >
>> >
>> >
>> > --
>> > Mike Tutkowski
>> > Senior CloudStack Developer, SolidFire Inc.
>> > e: mike.tutkowski@solidfire.com
>> > o: 303.746.7302
>> > Advancing the way the world uses the cloud™
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

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