<div dir="ltr">Nir,<div><br></div><div>Ah, I see. Makes sense, and thanks for chiming in with the correction so quickly. Bummer a quick rescan won't work for this scenario.</div><div><br></div><div>Thanks,</div><div>Jeff</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 24, 2017 at 11:50 AM, Nir Soffer <span dir="ltr"><<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.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="">On Fri, Feb 24, 2017 at 7:36 PM, Jeff Burns <<a href="mailto:admiraljkb@gmail.com">admiraljkb@gmail.com</a>> wrote:<br>
> Chris,<br>
><br>
> Sorry to chime in late, but this might help you (or someone with a similar<br>
> upgrade situation) in the future. The "rescan-scsi-bus.sh" script from the<br>
> sg3-utils package can handle the update for the size increase without the<br>
> reboot. Just need to run with the "-s" param to look for resized LUNs like<br>
> the below (run from a CentOS7.3 server):<br>
<br>
</span>This is not enough, you need to resize the multiapth mapping on all hosts,<br>
resize the pv using the LUN (must be done by the SPM), and invalidate<br>
vdsm lvm cache on all hosts, so they go to storage and see the new size of<br>
the pv.<br>
<span class="HOEnZb"><font color="#888888"><br>
Nir<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> ```<br>
> # rescan-scsi-bus.sh -s<br>
> Scanning SCSI subsystem for new devices<br>
> Searching for resized LUNs<br>
> 0 new or changed device(s) found.<br>
> 0 remapped or resized device(s) found.<br>
> 0 device(s) removed.<br>
> ```<br>
><br>
> Cheers<br>
> Jeff<br>
><br>
><br>
> On Fri, Feb 24, 2017 at 9:20 AM, Chris Adams <<a href="mailto:cma@cmadams.net">cma@cmadams.net</a>> wrote:<br>
>><br>
>> I did see that page, but... I can't get there from here. I can't get<br>
>> upgraded from 3.5 until I get past this problem, and on 3.5, the hosted<br>
>> engine storage domain isn't included in the normal UI at all.<br>
>><br>
>> I think I did get this working though; both servers had kernel messages<br>
>> that they saw the LUN resize, but they didn't actually change the block<br>
>> device size to reflect that. After rebooting each server (separately),<br>
>> lsblk showed the new size on both, and a manual pvresize on both shows<br>
>> the increased VG size.<br>
>><br>
>> On to testing 3.6 upgrade again!<br>
>><br>
>><br>
>> Once upon a time, Adam Litke <<a href="mailto:alitke@redhat.com">alitke@redhat.com</a>> said:<br>
>> > Hi Chris. We added this feature to newer versions of oVirt (see the<br>
>> > feature page[1]). The easiest way to work around this problem might be<br>
>> > to<br>
>> > add an additional LUN to this domain if you are able to do it. If not,<br>
>> > it<br>
>> > looks like you would need to manually reconnect the host to the domain,<br>
>> > to<br>
>> > a pvresize to the new size. I am not sure if any engine DB updates will<br>
>> > also be required. Nir and Fred worked on this feature and might be able<br>
>> > to<br>
>> > assist you further.<br>
>> ><br>
>> ><br>
>> > [1]<br>
>> ><br>
>> > <a href="https://www.ovirt.org/develop/release-management/features/storage/lun-resize/" rel="noreferrer" target="_blank">https://www.ovirt.org/develop/<wbr>release-management/features/<wbr>storage/lun-resize/</a><br>
>> ><br>
>> > On Fri, Feb 24, 2017 at 9:00 AM, Chris Adams <<a href="mailto:cma@cmadams.net">cma@cmadams.net</a>> wrote:<br>
>> ><br>
>> > > I'm testing upgrading an oVirt 3.5 setup, and I have run into a<br>
>> > > problem<br>
>> > > when going from 3.5 to 3.6 on a physical machine configured for the<br>
>> > > hosted engine. I upgraded the engine itself okay, but when I upgraded<br>
>> > > the first physical machine, it cannot be re-activated; it gets an<br>
>> > > error<br>
>> > > connecting to the storage domain.<br>
>> > ><br>
>> > > Checking the logs, it looks like it is looping trying to create a new<br>
>> > > LV<br>
>> > > in the HE VG. I assume this is for moving the HE config to the shared<br>
>> > > storage? It is failing because it is trying to create a 1G LV, but<br>
>> > > the<br>
>> > > VG only has 512M free space.<br>
>> > ><br>
>> > > I extended the iSCSI volume, but there doesn't appear to be anyway to<br>
>> > > get the HE nodes to recognize this; they both still see the original<br>
>> > > size, no matter what I try. Is there a way to get them to see the<br>
>> > > larger PV, so the new LV(s) can be created?<br>
>> > ><br>
>> > > --<br>
>> > > Chris Adams <<a href="mailto:cma@cmadams.net">cma@cmadams.net</a>><br>
>> > > ______________________________<wbr>_________________<br>
>> > > Users mailing list<br>
>> > > <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
>> > > <a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
>> > ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Adam Litke<br>
>><br>
>> > ______________________________<wbr>_________________<br>
>> > Users mailing list<br>
>> > <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
>> > <a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
>><br>
>><br>
>> --<br>
>> Chris Adams <<a href="mailto:cma@cmadams.net">cma@cmadams.net</a>><br>
>> ______________________________<wbr>_________________<br>
>> Users mailing list<br>
>> <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
>> <a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Users mailing list<br>
> <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
> <a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
><br>
</div></div></blockquote></div><br></div>