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<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> *™*
