Edison, For me, this issue comes back to the whole notion of the overloaded StoragePoolType. A hypervisor plugin should declare a method akin to getSupportedStorageProtocols() : ImmutableSet<StorageProtocol> which the Hypervisor layer can use to filter the available DataStores from the Storage subsystem. For example, as RBD support expands to other hypervisors, we should only have to modify those hypervisor plugins -- not the Hypervisor orchestration components or any aspect of the Storage layer.
Thanks, -John On Jun 17, 2013, at 4: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)*
