I think Zadara Storage will be looking to implement a plug-in in an upcoming release.
They have a similar use case to SolidFire where, I believe, their primary storage represents a SAN at the zone level. On Mon, Jun 17, 2013 at 2:54 PM, Edison Su <edison...@citrix.com> wrote: > But currently there is no such hypervisor layer yet, and to me it's > related to storage, not related to hypervisor. It's a property of a storage > to support one hypervisor, two hypervisors, or all the hypervisors, not a > property of hypervisor. > I agree, that add a hypervisor type on the storagepoolcmd is not a proper > solution, as we already see, it's not flexible enough for Solidfire. > How about add a getSupportedHypervisors on storage plugin, which will > return ImmutableSet<StorageProtocol>? > > > > -----Original Message----- > > From: John Burwell [mailto:jburw...@basho.com] > > Sent: Monday, June 17, 2013 1:42 PM > > To: dev@cloudstack.apache.org > > Subject: Re: Hypervisor Host Type Required at Zone Level for Primary > Storage? > > > > 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.ZoneWideStoragePoolAll > > >> ocat > > >> 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> *™*
