cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: Making use of a 4.2 storage plug-in from the GUI or API
Date Sat, 09 Mar 2013 06:04:12 GMT
Cloudstack wouldn't/shouldn't even get to the point of letting you do
that without zone-wide storage. It wouldn't think the lun was
available/reachable in that cluster. It would be like trying to start
a VM in a cluster it's not associated with. If the volume isn't on a
pool that is "in" the cluster, it's not going to even try to use it
there.

I'm not sure if zone-wide/cluster-wide are exclusive, but I don't
think so. It might be that you have to choose at the time of adding
the primary storage, but hopefully its implemented such that it can be
either if it's capable of being zone-wide. The functional spec
probably has the answers to this.

On Fri, Mar 8, 2013 at 6:45 PM, Mike Tutkowski
<mike.tutkowski@solidfire.com> wrote:
> There is a method to implement called grantAccess.
>
> Edison was telling me it is here where I enforce an ACL.  If a data disk
> were being migrated from one cluster to another, wouldn't this grantAccess
> method be called when the hypervisor in the other cluster was ready to
> access the volume?  At this point, I could add the IQN of the host in
> question into the ACL and the volume could be accessed by the host in the
> new cluster.
>
> Maybe I'm missing something here?
>
>
> On Fri, Mar 8, 2013 at 6:40 PM, Marcus Sorensen <shadowsor@gmail.com> wrote:
>
>> On that topic, I hope there's a method in the volume service that allows
>> plugin writers to handle volume copy directly.
>> On Mar 8, 2013 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
View raw message