<div dir="ltr"><font color="#000000">Thanks Sean. I filed a bug report to track this. <span style="font-family:Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif">Bug #1712651. I would agree with you on connectivity issues with the Netapp if it happened on all volume extensions, but this only happens in one scenario only.</span></font><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="background-color:rgb(255,255,255)">Thanks, </span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)">Adam</span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><span style="background-color:rgb(255,255,255)"><br></span></div><div><br></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Aug 23, 2017 at 2:04 PM, Sean McGinnis <span dir="ltr"><<a href="mailto:sean.mcginnis@gmx.com" target="_blank">sean.mcginnis@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Adam,<br>
<br>
There have been some updates since Liberty to improve handling in the os-brick<br>
library that handles the local device management. But with this showing the<br>
paths down, I wonder if there's something else going on there between the<br>
NetApp box and the Nova compute host.<br>
<br>
Could you file a bug to track this? I think you could just copy and paste the<br>
content of your original email since it captures a lot of great info.<br>
<br>
<a href="https://bugs.launchpad.net/cinder/+filebug" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>cinder/+filebug</a><br>
<br>
We can tag it with netapp so maybe it will get some attention there.<br>
<br>
Thanks,<br>
Sean<br>
<span class=""><br>
On Wed, Aug 23, 2017 at 01:01:24PM -0400, Adam Dibiase wrote:<br>
> Greetings,<br>
><br>
> I am having an issue with nova starting an instance that is using a root<br>
> volume that cinder has extended. More specifically, a volume that has been<br>
> extended past the max resize limit of our Netapp filer. I am running<br>
> Liberty and upgraded cinder packages to 7.0.3 from 7.0.0 to take advantage<br>
> of this functionality. From what I can gather, it uses sub-lun cloning to<br>
> get past the hard limit set by Netapp when cloning past 64G (starting from<br>
> a 4G volume).<br>
><br>
</span>> *Environment*:<br>
><br>
>    - Release: Liberty<br>
>    - Filer:       Netapp<br>
>    - Protocol: Fiberchannel<br>
>    - Multipath: yes<br>
><br>
><br>
><br>
> *Steps to reproduce: *<br>
><br>
>    - Create new instance<br>
>    - stop instance<br>
>    - extend the volume by running the following commands:<br>
>       - cinder reset-state --state available (volume-ID or name)<br>
>       - cinder extend (volume-ID or name) 100<br>
>       - cinder reset-state --state in-use (volume-ID or name)<br>
>    - start instance with either nova start or nova reboot --hard  --same<br>
<span class="">>    result<br>
><br>
><br>
> I can see that the instance's multipath status is good before the resize...<br>
><br>
</span>> *<wbr>360a98000417643556a2b496d58665<wbr>473 dm-17 NETAPP  ,LUN             *<br>
<span class="">><br>
> size=20G features='1 queue_if_no_path' hwhandler='0' wp=rw<br>
><br>
> |-+- policy='round-robin 0' prio=-1 status=active<br>
><br>
> | |- 6:0:1:5 sdy   65:128 active undef  running<br>
><br>
> | `- 7:0:0:5 sdz   65:144 active undef  running<br>
><br>
> `-+- policy='round-robin 0' prio=-1 status=enabled<br>
><br>
>   |- 6:0:0:5 sdx   65:112 active undef  running<br>
><br>
>   `- 7:0:1:5 sdaa  65:160 active undef  running<br>
><br>
><br>
> Once the volume is resized, the lun goes to a failed state and it does not<br>
> show the new size:<br>
><br>
><br>
</span>> *<wbr>360a98000417643556a2b496d58665<wbr>473 dm-17 NETAPP  ,LUN             *<br>
<span class="">><br>
> size=20G features='1 queue_if_no_path' hwhandler='0' wp=rw<br>
><br>
> |-+- policy='round-robin 0' prio=-1 status=enabled<br>
><br>
> | |- 6:0:1:5 sdy   65:128 failed undef  running<br>
><br>
> | `- 7:0:0:5 sdz   65:144 failed undef  running<br>
><br>
> `-+- policy='round-robin 0' prio=-1 status=enabled<br>
><br>
>   |- 6:0:0:5 sdx   65:112 failed undef  running<br>
><br>
>   `- 7:0:1:5 sdaa  65:160 failed undef  running<br>
><br>
><br>
> Like I said, this only happens on volumes that have been extended past 64G.<br>
> Smaller sizes to not have this issue. I can only assume that the original<br>
> lun is getting destroyed after the clone process and that is cause of the<br>
> failed state. Why is it not picking up the new one and attaching it to the<br>
> compute node?  Is there something I am missing?<br>
><br>
> Thanks in advance,<br>
><br>
> Adam<br>
<br>
</span>> ______________________________<wbr>_________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
<br>
</blockquote></div><br></div></div>