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