Do you know, Marcus, if it will be an either/or situation? In other words, will the plug-in have to be Zone wide or Cluster?
On Fri, Mar 8, 2013 at 6:32 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > It just depends. A VM will generally be tied to a cluster. There's > technically no reason why someone couldn't make a giant cluster if your > storage supports it, so on that side cluster based seems fine. But if you > end up wanting to move a data disk from one VM to another, and they happen > to be in different clusters, that's expensive if you don't have zone-wide > storage. Usually involves dumping and reimporting, and if the same San is > hosting multiple clusters it may seem silly to dump and copy back to the > same San just so that the disk is associated with another cluster. > On Mar 8, 2013 6:22 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> > wrote: > > > Thanks for that explanation, Marcus. > > > > I believe the primary use case for me is to allow a cluster of hosts > > (XenServer, VMware, or KVM in particular) to share access to my iSCSI > > target (we would have a mapping of one VM per iSCSI target or one data > disk > > per iSCSI target). > > > > I can't really see why hosts outside of the cluster would need access to > it > > unless you actually are migrating the VM that's running on that volume to > > another cluster. > > > > > > On Fri, Mar 8, 2013 at 6:16 PM, Marcus Sorensen <shadow...@gmail.com> > > wrote: > > > > > Cluster wide is good for storage that requires some sort of > organization > > > path the host level, for example, mounted file systems that rely on > > cluster > > > locking, like OCFS, GFS, cluster LVM, where hosts that aren't in a > > cluster > > > can't make use of the storage. Xen's SR's are sort of like this as > well, > > > actually almost identical to cluster LVM where it carves volumes out > of a > > > pool or lun, leveraging locking mechanisms in the xen cluster. Cluster > > wide > > > is also good for topologies that are simply laid out in a way that > makes > > > sense for it, for example if you had a 10g switch dedicated to a > > particular > > > cluster, with NFS services over it. > > > > > > It boils down to whether every host in the zone can access/make use of > > the > > > storage or whether only certain hosts can. > > > On Mar 8, 2013 6:04 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com > > > > > wrote: > > > > > > > Hey Edison, > > > > > > > > It is entirely possible that Zone wide for my plug-in would make > sense. > > > > I'm trying to understand what restrictions, if any, are in place if > it > > > is > > > > Zone wide versus Cluster wide. > > > > > > > > In my case, the plug-in I'm developing will be creating an iSCSI > target > > > > (volume/LUN) (nothing NFS related) and if that is best to make > > available > > > at > > > > a Zone level, that is totally fine with me. > > > > > > > > What would you suggest for my situation? > > > > > > > > Thanks! > > > > > > > > > > > > On Fri, Mar 8, 2013 at 5:35 PM, Edison Su <edison...@citrix.com> > > wrote: > > > > > > > > > That API will be easy to be added, and yes, I’ll add it next > > week.**** > > > > > > > > > > In the last email, I just give zone-wide primary storage as an > > example, > > > > > and I thought your storage box will be zone-wide? As you can see, > > > > > createstoragepoolcmd api is quite flexible, it can be used for > > > > > zone-wide/cluster storage, so do the storage plugin.**** > > > > > > > > > > ** ** > > > > > > > > > > *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > > > > > *Sent:* Friday, March 08, 2013 4:09 PM > > > > > *To:* Edison Su > > > > > *Cc:* cloudstack-dev@incubator.apache.org > > > > > *Subject:* Re: Making use of a 4.2 storage plug-in from the GUI or > > > > API**** > > > > > > > > > > ** ** > > > > > > > > > > OK, cool - thanks for the info, Edison.**** > > > > > > > > > > ** ** > > > > > > > > > > When you say, "One API is missing," does that mean you're still > > working > > > > on > > > > > implementing that functionality?**** > > > > > > > > > > ** ** > > > > > > > > > > Also, it sounds like these plug-ins are associated with Zone-wide > > > Primary > > > > > Storage. I thought Zone-wide Primary Storage wasn't available for > > all > > > > > hypervisors?**** > > > > > > > > > > ** ** > > > > > > > > > > This is from a different e-mail you sent out: > > > > > > > > > > "Xenserver and vmware doesn’t support zone wide primary storage, > > > > > currently, this feature is only for NFS/Ceph in KVM. And I think it > > > > should > > > > > be useful for your storage box? I am thinking per data volume per > LUN > > > for > > > > > xenserver."**** > > > > > > > > > > ** ** > > > > > > > > > > I'm not sure how my plug-in would work with XenServer, VMware, etc. > > if > > > it > > > > > has to be Zone-wide.**** > > > > > > > > > > ** ** > > > > > > > > > > Can you clarify this for me?**** > > > > > > > > > > ** ** > > > > > > > > > > Thanks!**** > > > > > > > > > > ** ** > > > > > > > > > > On Fri, Mar 8, 2013 at 4:33 PM, Edison Su <edison...@citrix.com> > > > > wrote:*** > > > > > * > > > > > > > > > > One API is missing, liststorageproviderscmd, which will list all > the > > > > > storage providers registered in the mgt server. **** > > > > > > > > > > When adding a zone wide storage pool on the UI, the UI will have a > > > > > drop-down list to show all the primary storage providers. Then user > > > will > > > > > choose one of them, and select some other parameters for the > storage > > > user > > > > > wants to add. At the end, UI will call, createstoragepoolcmd, with > > > > > provider=the-storage-provider-uuid-returned from > > liststoageprovidercmd, > > > > > scope=zone, and other input parameters. Mgt server will then call > > > > > corresponding storage provider based on provider uuid, to register > > the > > > > > storage into cloudstack.**** > > > > > > > > > > **** > > > > > > > > > > *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > > > > > *Sent:* Friday, March 08, 2013 2:46 PM > > > > > *To:* cloudstack-dev@incubator.apache.org > > > > > *Cc:* Edison Su > > > > > *Subject:* Making use of a 4.2 storage plug-in from the GUI or > > API**** > > > > > > > > > > **** > > > > > > > > > > Hi,**** > > > > > > > > > > **** > > > > > > > > > > As you may remember, I'm leveraging Edison's new (4.2) storage > > plug-in > > > > > framework to build what is probably the first such plug-in for > > > > CloudStack. > > > > > **** > > > > > > > > > > **** > > > > > > > > > > I was wondering, does anyone know how to make the system aware of > the > > > > > plug-in? I believe once the plug-in is ready (i.e. usable) that > the > > > > intent > > > > > is to be able to select it when creating Primary Storage (instead > of > > > > having > > > > > to select a pre-existent iSCSI target).**** > > > > > > > > > > **** > > > > > > > > > > I'm curious how to get this working (i.e. select my plug-in) in the > > GUI > > > > > and via the API.**** > > > > > > > > > > **** > > > > > > > > > > Thanks!**** > > > > > > > > > > **** > > > > > > > > > > -- > > > > > *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> > > > > *™* > > > > > > > > > > > > > > > -- > > *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> *™*
