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

Reply via email to