What do we do, though, if the storage can only work on a subset of the ones
listed in the enum?

For example, XenServer and VMware.


On Mon, Jun 17, 2013 at 2:27 PM, Edison Su <edison...@citrix.com> wrote:

> There are storages which can only work with one hypervisor,
>  e.g. Currently, Ceph can only work on KVM. And the data store created in
> VCenter, can only work with Vmware.
>
>
>
> > -----Original Message-----
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: Monday, June 17, 2013 1:12 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: Hypervisor Host Type Required at Zone Level for Primary
> Storage?
> >
> > I figured you might have something to say about this, John. :)
> >
> > Yeah, I have no idea behind the motivation for this change other than
> what
> > Edison just said in a recent e-mail.
> >
> > It sounds like this change went in so that the allocators could look at
> the VM
> > characteristics and see the hypervisor type. With this info, the
> allocator can
> > decide if a particular zone-wide storage is acceptable. This doesn't
> apply for
> > my situation as I'm dealing with a SAN, but some zone-wide storage is
> static
> > (just a volume "out there" somewhere). Once this volume is used for, say,
> > XenServer purposes, it can only be used for XenServer going forward.
> >
> > For more details, I would recommend Edison comment.
> >
> >
> > On Mon, Jun 17, 2013 at 2:01 PM, John Burwell <jburw...@basho.com>
> > wrote:
> >
> > > Mike,
> > >
> > > I know my thoughts will come as a galloping shock, but the idea of a
> > > hypervisor type being attached to a volume is the type of dependency I
> > > think we need to remove from the Storage layer.  What attributes of a
> > > DataStore/StoragePool require association to a hypervisor type?  My
> > > thought is that we should expose query methods allow the Hypervisor
> > > layer to determine if a DataStore/StoragePool requires such a
> > > reservation, and we track that reservation in the Hypervisor layer.
> > >
> > > Thanks,
> > > -John
> > >
> > > On Jun 17, 2013, at 3:48 PM, Mike Tutkowski
> > > <mike.tutkow...@solidfire.com>
> > > wrote:
> > >
> > > > Hi Edison,
> > > >
> > > > How's about if I add this logic into ZoneWideStoragePoolAllocator
> > > (below)?
> > > >
> > > > After filtering storage pools by tags, it saves off the ones that
> > > > are for any hypervisor.
> > > >
> > > > Next, we filter the list down more by hypervisor.
> > > >
> > > > Then, we add the storage pools back into the list that were for any
> > > > hypervisor.
> > > >
> > > > @Override
> > > >
> > > > protected List<StoragePool> select(DiskProfile dskCh,
> > > >
> > > > VirtualMachineProfile<? extends VirtualMachine> vmProfile,
> > > >
> > > > DeploymentPlan plan, ExcludeList avoid, int returnUpTo) {
> > > >
> > > >    s_logger.debug("ZoneWideStoragePoolAllocator to find storage
> > > > pool");
> > > >
> > > > List<StoragePool> suitablePools = new ArrayList<StoragePool>();
> > > >
> > > >
> > > >        List<StoragePoolVO> storagePools =
> > > >
> > _storagePoolDao.findZoneWideStoragePoolsByTags(plan.getDataCenterId(
> > > > ),
> > > > dskCh.getTags());
> > > >
> > > >
> > > >        if (storagePools == null) {
> > > >
> > > >            storagePools = new ArrayList<StoragePoolVO>();
> > > >
> > > >        }
> > > >
> > > >
> > > >        List<StoragePoolVO> anyHypervisorStoragePools =
> > > > newArrayList<StoragePoolVO>();
> > > >
> > > >
> > > >        for (StoragePoolVO storagePool : storagePools) {
> > > >
> > > >            if
> > > > (storagePool.getHypervisor().equals(HypervisorType.Any)) {
> > > >
> > > >                anyHypervisorStoragePools.add(storagePool);
> > > >
> > > >            }
> > > >
> > > >        }
> > > >
> > > >
> > > >        List<StoragePoolVO> storagePoolsByHypervisor =
> > > >
> > >
> > _storagePoolDao.findZoneWideStoragePoolsByHypervisor(plan.getDataCent
> > e
> > > rId(),
> > > > dskCh.getHypervisorType());
> > > >
> > > >
> > > >        storagePools.retainAll(storagePoolsByHypervisor);
> > > >
> > > >
> > > >        storagePools.addAll(anyHypervisorStoragePools);
> > > >
> > > >
> > > >        // add remaining pools in zone, that did not match tags, to
> > > > avoid set
> > > >
> > > >        List<StoragePoolVO> allPools =
> > > >
> > _storagePoolDao.findZoneWideStoragePoolsByTags(plan.getDataCenterId(
> > > > ),
> > > > null);
> > > >
> > > >        allPools.removeAll(storagePools);
> > > >
> > > >        for (StoragePoolVO pool : allPools) {
> > > >
> > > >            avoid.addPool(pool.getId());
> > > >
> > > >        }
> > > >
> > > >
> > > >        for (StoragePoolVO storage : storagePools) {
> > > >
> > > >            if (suitablePools.size() == returnUpTo) {
> > > >
> > > >                break;
> > > >
> > > >            }
> > > >
> > > >            StoragePool pol = (StoragePool)this.dataStoreMgr
> > > > .getPrimaryDataStore(storage.getId());
> > > >
> > > >            if (filter(avoid, pol, dskCh, plan)) {
> > > >
> > > >                suitablePools.add(pol);
> > > >
> > > >            } else {
> > > >
> > > >                avoid.addPool(pol.getId());
> > > >
> > > >            }
> > > >
> > > >        }
> > > >
> > > >        return suitablePools;
> > > >
> > > >    }
> > > >
> > > >
> > > > On Mon, Jun 17, 2013 at 11:40 AM, Mike Tutkowski <
> > > > mike.tutkow...@solidfire.com> wrote:
> > > >
> > > >> 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+prima
> > > ry+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.ZoneWideStoragePoolAllocat
> > or"
> > > >>> />
> > > >>> 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>
> > > >> *(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>
> > > > *(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>
> > *(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