Hi Edison,

I haven't looked into this much, so maybe what I suggest here won't make
sense, but here goes:

What about a Hypervisor.MULTIPLE enum option ('Hypervisor' might not be the
name of the enumeration...I forget). The ZoneWideStoragePoolAllocator could
use this to be less choosy about if a storage pool qualifies to be used.

Does that make any sense?

Thanks!


On Mon, Jun 17, 2013 at 11:28 AM, Edison Su <edison...@citrix.com> wrote:

> I think it's due to this
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Zone-wide+primary+storage+target
> There are zone-wide storages, may only work with one particular
> hypervisor. For example, the data store created on VCenter can be shared by
> all the clusters in a DC, but only for vmware. And, CloudStack supports
> multiple hypervisors in one Zone, so, somehow, need a way to tell mgt
> server, for a particular zone-wide storage, which can only work with
> certain hypervisors.
> You can treat hypervisor type on the storage pool, is another tag, to help
> storage pool allocator to find proper storage pool. But seems hypervisor
> type is not enough for your case, as your storage pool can work with both
> vmware/xenserver, but not for other hypervisors(that's your current code's
> implementation limitation, not your storage itself can't do that).
> So I'd think you need to extend ZoneWideStoragePoolAllocator, maybe, a new
> allocator called: solidfirezonewidestoragepoolAllocator. And, replace the
> following line in applicationContext.xml:
>   <bean id="zoneWideStoragePoolAllocator"
> class="org.apache.cloudstack.storage.allocator.ZoneWideStoragePoolAllocator"
> />
> With your solidfirezonewidestoragepoolAllocator
> It also means, for each CloudStack mgt server deployment, admin needs to
> configure applicationContext.xml for their needs.
>
> > -----Original Message-----
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: Saturday, June 15, 2013 11:34 AM
> > To: dev@cloudstack.apache.org
> > Subject: Hypervisor Host Type Required at Zone Level for Primary Storage?
> >
> > Hi,
> >
> > I recently updated my local repo and noticed that we now require a
> > hypervisor type to be associated with zone-wide primary storage.
> >
> > I was wondering what the motivation for this might be?
> >
> > In my case, my zone-wide primary storage represents a SAN. Volumes are
> > carved out of the SAN as needed and can currently be utilized on both Xen
> > and VMware (although, of course, once you've used a given volume on one
> > hypervisor type or the other, you can only continue to use it with that
> > hypervisor type).
> >
> > I guess the point being my primary storage can be associated with more
> than
> > one hypervisor type because of its dynamic nature.
> >
> > Can someone fill me in on the reasons behind this recent change and
> > recommendations on how I should proceed here?
> >
> > 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>
> > *(tm)*
>



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

Reply via email to