Open Stack

On Thu, Jun 23, 2016 at 12:07:43PM -0600, Chris Friesen wrote:
> 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

I'm curious to find out this as well. Is this for a performance gain? If
so, do we have any metrics showing that gain is significant enough to
warrant making a change like this?

The host OS is still going to be involved. AFAIK, this just cuts out the
software iSCSI initiator from the picture. So we would be moving from a
piece of software dedicated to one specific functionality, to a
different piece of software that's main reason for existence is nothing
to do with IO path management.

I'm not saying I'm completely opposed to this. If there is a reason for
doing it then it could be worth it. But so far I haven't seen anything
explaining why this would be better than what we have today.

> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev