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
