[ovirt-users] Recognize HE iSCSI volume size change

[Jeff Burns]

Nir,

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.

Thanks,
Jeff

On Fri, Feb 24, 2017 at 11:50 AM, Nir Soffer <nsoffer at redhat.com> wrote:

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