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.getDataCenterId(), > 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+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> >> *™* >> > > > > -- > *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> > *™*