Interesting...thanks!
On Wed, Mar 20, 2013 at 8:21 PM, Marcus Sorensen <shadow...@gmail.com>wrote: > That's where I'm not sure. Its been a few years, and we always used vmfs, > which is more of the shared pool model. VMware wants to have something to > carve up rather than 1 disk per VM disk, but that doesn't mean it isn't > possible. > > We've been building our own custom primary storage, but doing it in 4.1, > since we don't want to wait. There's a decent amount of work to do on the > host to get the disks connected up and usable, identified, and mapped to > the right things ready for VMs. That work will exist even after the storage > framework is in place. The work is done on the host by agent storage > adaptors in KVM, I'm not sure if xen and VMware have an equivalent or if > they just rely on xen and VMware supported pool types. > On Mar 20, 2013 8:11 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> > wrote: > >> Hey Marcus, >> >> How do you see this plug-in working with VMware? >> >> >> On Wed, Mar 20, 2013 at 8:11 PM, Mike Tutkowski < >> mike.tutkow...@solidfire.com> wrote: >> >>> I see...cool - thanks, Marcus! >>> >>> >>> On Wed, Mar 20, 2013 at 8:08 PM, Marcus Sorensen <shadow...@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.tutkow...@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 <shadow...@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.tutkow...@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.tutkow...@solidfire.com >>>> >>> o: 303.746.7302 >>>> >>> Advancing the way the world uses the cloud™ >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Mike Tutkowski >>>> > Senior CloudStack Developer, SolidFire Inc. >>>> > e: mike.tutkow...@solidfire.com >>>> > o: 303.746.7302 >>>> > Advancing the way the world uses the cloud™ >>>> >>> >>> >>> >>> -- >>> *Mike Tutkowski* >>> *Senior CloudStack Developer, SolidFire Inc.* >>> e: mike.tutkow...@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.tutkow...@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.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
