<div dir="ltr">Daniel, Thanks. Looking for a sense of direction.<div><br></div><div>Clearly there is some range of opinion, as Walter indicates. :)<br><br>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.</div><div><br></div><div>I <i>suspect</i> 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.)</div><div><br></div><div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 23, 2016 at 9:09 AM, Walter A. Boring IV <span dir="ltr"><<a href="mailto:walter.boring@hpe.com" target="_blank">walter.boring@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
volumes connected to QEMU instances eventually become directly connected?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Our long term goal is that 100% of all network storage will be connected<br>
to directly by QEMU. We already have the ability to partially do this with<br>
iSCSI, but it is lacking support for multipath. As & when that gap is<br>
addressed though, we'll stop using the host OS for any iSCSI stuff.<br>
<br>
So if you're requiring access to host iSCSI volumes, it'll work in the<br>
short-medium term, but in the medium-long term we're not going to use<br>
that so plan accordingly.<br>
</blockquote>
<br></span>
What is the benefit of this largely monolithic approach?  It seems that<br>
moving everything into QEMU is diametrically opposed to the unix model itself and<br>
is just a re-implementation of what already exists in the linux world outside of QEMU.<br>
<br>
Does QEMU support hardware initiators? iSER?<br>
<br>
We regularly fix issues with iSCSI attaches in the release cycles of OpenStack,<br>
because it's all done in python using existing linux packages.  How often are QEMU<br>
releases done and upgraded on customer deployments vs. python packages (os-brick)?<br>
<br>
I don't see a compelling reason for re-implementing the wheel,<br>
and it seems like a major step backwards.<span class="im HOEnZb"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Xiao's unanswered query (below) presents another question. Is this a<br>
site-choice? Could I require my customers to configure their OpenStack<br>
clouds to always route iSCSI connections through the nova-compute host? (I<br>
am not a fan of this approach, but I have to ask.)<br></blockquote></blockquote></span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>
In the short term that'll work, but long term we're not intending to<br>
support that once QEMU gains multi-path. There's no timeframe on when<br>
that will happen though.<br><br>
<br>
Regards,<br>
Daniel<br>
</blockquote>
</span></blockquote></div><br></div></div></div></div>