<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 6, 2016 at 10:19 AM, Gary Lloyd <span dir="ltr">&lt;<a href="mailto:g.lloyd@keele.ac.uk" target="_blank">g.lloyd@keele.ac.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I asked on the Dell Storage Forum and they recommend the following:<div><br></div><div><p style="font-family:arial,helvetica,sans-serif;font-size:13.3333px"><i>I recommend not using a numeric value for the &quot;no_path_retry&quot; variable within /etc/multipath.conf as once that numeric value is reached, if no healthy LUNs were discovered during that defined time multipath will disable the I/O queue altogether.</i></p><p style="font-family:arial,helvetica,sans-serif;font-size:13.3333px"><i>I do recommend, however, changing the variable value from &quot;12&quot; (or even &quot;60&quot;) to &quot;queue&quot; which will then allow multipathd to continue queing I/O until a healthy LUN is discovered (time of fail-over between controllers) and I/O is allowed to flow once again.</i></p><p style="font-family:arial,helvetica,sans-serif;font-size:13.3333px"><span style="font-size:13.3333px">Can you see any issues with this recommendation as far as Ovirt is concerned ?</span></p></div></div></blockquote><div>Yes, we cannot work with unlimited queue. This will block vdsm for unlimited</div><div>time when the next command try to access storage. Because we don&#39;t have</div><div>good isolation between different storage domains, this may cause other storage</div><div>domains to become faulty. Also engine flows that have a timeout will fail with</div><div>a timeout.</div><div><br></div><div>If you are on 3.x, this will be very painfull, on 4.0 it should be better, but it is not</div><div>recommended.</div><div><br></div><div>Nir</div><div><br></div></div></div></div>