Open Stack

On 06/23/2016 10:09 AM, Walter A. Boring IV 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.

This is an interesting point.

Unless there's a significant performance benefit to connecting directly from 
qemu, it seems to me that we would want to leverage the existing work done by 
the kernel and other "standard" iSCSI initators.

Chris