cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Making use of a 4.2 storage plug-in from the GUI or API
Date Sat, 09 Mar 2013 01:41:39 GMT
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 <shadowsor@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.tutkowski@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 <shadowsor@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.tutkowski@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.su@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.tutkowski@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.su@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message