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