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