Open Stack

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.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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160623/2485a96e/attachment.html>