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. 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.bor...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev