cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Hypervisor Host Type Required at Zone Level for Primary Storage?
Date Mon, 17 Jun 2013 21:09:44 GMT
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 <jburwell@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.su@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:jburwell@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.su@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.tutkowski@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 <jburwell@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.tutkowski@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.tutkowski@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.su@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message