incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: [DISCUSS] Zone-wide primary storage target
Date Fri, 04 Jan 2013 20:08:18 GMT
Hari,

Is there a requirement on a ebs volume created for one hypervisor can be attached to on another
hypervisor?  Or once created, it can only be attach to the same hypervisor?

--Alex

> -----Original Message-----
> From: Hari Kannan [mailto:hari.kannan@citrix.com]
> Sent: Friday, January 04, 2013 8:45 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Zone-wide primary storage target
> 
> Hi Edison
> 
> I don't think we have the option of saying that if you want this feature, a
> zone has to have only one hypervisor type - not only do we have customer(s)
> with more than one hyperisor type in a zone, many customers will state that
> this is their eventual goal to provide differentiated level of service (VMware
> for "gold", XS for silver etc.) - also, the UI workflow, error checking etc.
> changes may be pervasive - plus, this is good for demos :-) so, I cant imagine
> we could say that this features means you cant have a heterogeneous zone,
> if that is what you are saying..
> 
> Regarding " vmware has the limitation on how many data stores can be
> attached to a vcenter" - can you please elaborate how it impacts this feature?
> 
> Hari
> 
> -----Original Message-----
> From: Edison Su [mailto:Edison.su@citrix.com]
> Sent: Thursday, January 3, 2013 4:21 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Zone-wide primary storage target
> 
> Don't get things tooo complicated, let's make the simple thing work:
> One hypervisor in one zone, with one or multiple zone-wide primary
> storages. Without any special configurations, NFS/ceph + KVM can work
> under this configuration.
> If there are storage providers which can provide per volume per ISCSI LUN in
> a scalable way, then XS/KVM can work under this configuration.  E.g. for Xs,
> each volume will become a SR, XS should support it? So we can add two
> hypervisors in one zone, with multiple zone-wide storages.
> I heard of that, vmware has the limitation on how many data stores can be
> attached to a vcenter. If that's the case, then we may have problems to
> support this feature for VMware.
> Then, if admin just adds a Vmware cluster and kvm/XS cluster into one zone,
> with both cluster-wide and zone-wide primary storages, what can we do?
> 1. If the storage allocator is smart enough, which helps to choose the right
> storage to create volume in different situations. For example, the storage
> allocator should know, oh, I can't create volume on a zone-wide storage, if
> the hypervisor host is vmware etc.
> 2. or, admin is smart enough, which can tag the storages differently. E.g. VM
> created on Vmware cluster can only be created on a storage tagged by
> "vmware", if the disk offering has "vmware"
>  Tag, while VM created on KVM/XS, can be created on storages which has
> "zone-wide" tag, etc.
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Hari Kannan [mailto:hari.kannan@citrix.com]
> > Sent: Thursday, January 03, 2013 2:35 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: [DISCUSS] Zone-wide primary storage target
> >
> > Actually, let me clarify my original question, as re-reading it seems
> > like it was misleading. Since all hypervisors don't support this
> > capability (for example, XS doesn't), but a zone can be heterogeneous
> > (from a hypervisor perspective), we need to support the capability to
> > allow both zone-wide and cluster-only primary storage for any zone. I
> > was wondering if a single cluster needs to support both, seems like it is a
> nice to have?
> >
> > Can you elaborate on the "disk offering" comment - are you suggesting
> > we provide the end user the following choices
> >
> > a) local disk (we have this today already)
> > b) zone wide (new - but we indirectly provide this capability already,
> > as CS copies between primary stores if needed - but explicitly
> > choosing this option means finding storage only on the shared store.
> > If not chosen, preference is to place in shared store, if not possible
> > place in cluster-specific primary store
> 
> >
> > we still may not be able to avoid "double" copy - if we have to
> > unmount the disk and remount on a cluster that does NOT have shared
> > zone-wide primary store (or vice-versa), we still may have to resort
> > to the double copy as is done today -
> 
> >
> > Hari
> >
> > -----Original Message-----
> > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> > Sent: Thursday, January 3, 2013 1:51 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: [DISCUSS] Zone-wide primary storage target
> >
> >
> >
> > > -----Original Message-----
> > > From: Hari Kannan [mailto:hari.kannan@citrix.com]
> > > Sent: Thursday, January 03, 2013 1:46 PM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: RE: [DISCUSS] Zone-wide primary storage target
> > >
> > > Hi Alex, Chip,
> > >
> > > That's easy, I will change the name :-)
> > >
> > > @ Alex, I wasn't explicitly expecting co-existence of zone-wide
> > > primary storage and a "local" (cluster-wide only) primary storage.
> > > It seems you have assumed that would be a basic requirement, just
> > > wanted
> > to confirm.
> >
> > No I was giving one use case of where this capability might be useful.
> > It's not a requirement.
> >
> > >
> > > If that were the case, when a user requests a data volume, must
> > > there be an option to choose or how will the allocation work? Will
> > > data volumes always come out of the zone-wide storage and root
> > > volume always is local or cluster- based primary storage?
> >
> > I assume those will go into the disk offering.
> >
> > >
> > > Finally, should we allow multiple zone-wide primary storage?
> >
> > Yes.  Every time we plan for only one, it has come back to bite us
> > because physical limits of the resources.  We can certainly present to
> > the end user as one zone wide ebs like storage but how it's
> > implemented underneath shouldn't be limited.
> >
> > --Alex

Mime
View raw message