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