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