Open Stack

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