[openstack-dev] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

Sean McGinnis sean.mcginnis at gmx.com
Thu Jun 23 20:22:30 UTC 2016


On Thu, Jun 23, 2016 at 09:50:11AM -0700, Preston L. Bannister wrote:
> Daniel, Thanks. Looking for a sense of direction.
> 
> Clearly there is some range of opinion, as Walter indicates. :)
> 
> Not sure you are get to 100% direct connection to QEMU. When there is
> dedicated hardware to do off-board processing of the connection to storage,
> you might(?) be stuck routing through the nova-compute host Linux. (I am
> not an expert in this area, so I could easily be wrong.) This sort of
> hardware tends to be associated with higher-end "enterprise" storage and
> hosts (and higher cost). The storage guys are in the habit of calling these
> "HBA adaptors" (for high-bandwidth) - might just be a local thing.

nit: HBA == Host Bus Adapter

:)
> 
> I *suspect* that higher cost will drive most cloud deployments away from
> that sort of specialized hardware. In which case the direct-connect to QEMU
> model should (mostly?) work. (My non-expert guess.)
> 
> 
> 
> On Thu, Jun 23, 2016 at 9:09 AM, Walter A. Boring IV <walter.boring at hpe.com>
> wrote:
> 
> >
> > volumes connected to QEMU instances eventually become directly connected?
> >
> > Our long term goal is that 100% of all network storage will be connected
> >> to directly by QEMU. We already have the ability to partially do this with
> >> iSCSI, but it is lacking support for multipath. As & when that gap is
> >> addressed though, we'll stop using the host OS for any iSCSI stuff.
> >>
> >> So if you're requiring access to host iSCSI volumes, it'll work in the
> >> short-medium term, but in the medium-long term we're not going to use
> >> that so plan accordingly.
> >>
> >
> > What is the benefit of this largely monolithic approach?  It seems that
> > moving everything into QEMU is diametrically opposed to the unix model
> > itself and
> > is just a re-implementation of what already exists in the linux world
> > outside of QEMU.
> >
> > Does QEMU support hardware initiators? iSER?
> >
> > We regularly fix issues with iSCSI attaches in the release cycles of
> > OpenStack,
> > because it's all done in python using existing linux packages.  How often
> > are QEMU
> > releases done and upgraded on customer deployments vs. python packages
> > (os-brick)?
> >
> > I don't see a compelling reason for re-implementing the wheel,
> > and it seems like a major step backwards.
> >
> >
> >> Xiao's unanswered query (below) presents another question. Is this a
> >>> site-choice? Could I require my customers to configure their OpenStack
> >>> clouds to always route iSCSI connections through the nova-compute host?
> >>> (I
> >>> am not a fan of this approach, but I have to ask.)
> >>>
> >>
> 
> > In the short term that'll work, but long term we're not intending to
> >> support that once QEMU gains multi-path. There's no timeframe on when
> >> that will happen though.
> >>
> >>
> >> Regards,
> >> Daniel
> >>
> >

> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list