Edison, As part of the hack day discussion, I think we need to determine how to establish that layer and invert these dependencies. Hypervisors must know about storage and network devices. A VM is the nexus of a particular set of storage devices/volumes and network devices/interfaces. From an architectural perspective, we sustain a system circular dependencies between these layers. Since VM must know about storage and networking, I want to invert the dependencies such that storage and network are hypervisor agnostic. I believe it is entirely feasible, and will yield a more robust, general purpose storage layer with wider potential use than just to support hypervisors.
Thanks, -John On Jun 17, 2013, at 4: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)* >
