I think a hack-day session on this would be great. To me, since we're so late in the game for 4.2, I think we need to take two approaches here: 1) Short-term solution for 4.2 (that hopefully will not make future refactoring work too much more difficult than it might already be) and 2) Long-term solution such as what John is talking about.
On Mon, Jun 17, 2013 at 3:03 PM, John Burwell <jburw...@basho.com> wrote: > 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)* > > > > -- *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> *™*
