Description of problem: When a LUN is resized the change is not picked up by the multipath dm. LUN size 23Gb # lsblk /dev/sda NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 23G 0 disk └─36001405af7d8dcb723f4492b2649f4e8 (dm-0) 253:0 0 23G 0 mpath LUN resized to 24Gb # iscsiadm -m node -R # lsblk /dev/sda NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 24G 0 disk └─36001405af7d8dcb723f4492b2649f4e8 (dm-0) 253:0 0 23G 0 mpath # multipath # lsblk /dev/sda NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 24G 0 disk └─36001405af7d8dcb723f4492b2649f4e8 (dm-0) 253:0 0 23G 0 mpath # multipath -r reload: 36001405af7d8dcb723f4492b2649f4e8 undef LIO-ORG,FILEIO NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 24G 0 disk └─36001405af7d8dcb723f4492b2649f4e8 (dm-0) 253:0 0 24G 0 mpath VDSM recently removed the use of the "-r" parameter in commit: db012cb mutipath: Remove unneeded and dangerous -r parameter We should understand if this is the expected multipath behavior (and reintroduce the parameter in vdsm) or if we should open a multipath bug and use this bz to commit a spec requirement for the new package. Version-Release number of selected component (if applicable): vdsm-4.14.7-5.el6ev How reproducible: 100% Steps to Reproduce: 1. Resize a LUN on the storage 2. Follow the steps mentioned above Actual results: The LUN size is not picked up by the multipath dm. Expected results: The LUN size should be picked up by the multipath dm.
More info: Kernel 2.6.32-431.20.3.el6.x86_64 device-mapper-multipath-0.4.9-72.el6_5.3.x86_64 device-mapper-1.02.79-8.el6.x86_64
Ben, can you take a look at this? In https://bugzilla.redhat.com/show_bug.cgi?id=1078879#c18 you wrote: # Multipath -r really isn't useful for much of anything, and It seemed to be required so multipath pick changes in the lun size. Maybe we did not understand your recommendation?
I'm confused. Running # service multipathd reload should pick up a resize just as well as running "multipath -r". Is that not what you are seeing?
(In reply to Ben Marzinski from comment #3) > I'm confused. Running > > # service multipathd reload > > should pick up a resize just as well as running "multipath -r". Is that not > what > you are seeing? Are you saying that multipathd is not automatically picking up lun resizes and we have either run multipathd reload or "multipath -r"?
Yes. You need to manually run # service multipathd reload or # multipath -r Running # service multipathd reload is generally better, since running # multipath -r will not update anything in the daemon except a change in the device table. However, in the case of a device resize, that's all that is changing, so # multipath -r should work fine.
We cannot use multipath -r because it may cause a segfault in multipathd (bug 1080052). This will be fixed in el6.6. So the only option left is running "vdsm-tool service-reload multipathd" when we run today "multipath".
(In reply to Nir Soffer from comment #6) > We cannot use multipath -r because it may cause a segfault in multipathd > (bug 1080052). This will be fixed in el6.6. > > So the only option left is running "vdsm-tool service-reload multipathd" > when we run today "multipath". Pushing out to RHEV 3.6 to consume the RHEL 6.6 fix.
For RHEV 3.6.0 we'll no longer support RHEL6, so we can move forward with this BZ.
*** Bug 1223456 has been marked as a duplicate of this bug. ***
As part of the RFE described in bug 609689, multipath should resize luns when VDSM issues ConnectStorageServer, or manually when you resize a lun via the engine. That should be sufficient to cover this flow.
LUN resize is now picked up by VDSM and recognized by engine during getDeviceList as part of 609689. Steps: - Created and exposed a 43G LUN to the host sdax 67:16 0 43G 0 disk └─360060160f4a0300002939236a8e6e411 253:67 0 43G 0 mpath - Created a storage domain out of the LUN - Resized the LUN from the storage server to 50G - Edited the storage domain. Via Webadmin, the option to increase the size of the storage domain resides on the resized LUN was available. Resized and confirmed. - Created successfully a 40G preallocated virtual disk on this domain. Multipath now shows the new size of the LUN (50G): sdax 67:16 0 43G 0 disk └─360060160f4a0300002939236a8e6e411 253:67 0 43G 0 mpath Verified using ovirt-3.6.0-5
Sorry, copy-paste issue, here is the updated lsblk output for this LUN: sdax 67:16 0 50G 0 disk └─360060160f4a0300002939236a8e6e411 253:67 0 50G 0 mpath
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0362.html