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