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