Bug 1117385 - LUN resize not picked up by multipath on VDSM refresh
Summary: LUN resize not picked up by multipath on VDSM refresh
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
high
urgent
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Fred Rolland
QA Contact: Elad
URL:
Whiteboard:
: 1223456 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-08 14:44 UTC by Federico Simoncelli
Modified: 2019-07-11 08:02 UTC (History)
8 users (show)

Fixed In Version: vdsm-4.17.0-1198.git6ede99a
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-09 19:23:06 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0362 0 normal SHIPPED_LIVE vdsm 3.6.0 bug fix and enhancement update 2016-03-09 23:49:32 UTC

Description Federico Simoncelli 2014-07-08 14:44:07 UTC
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.

Comment 1 Federico Simoncelli 2014-07-08 14:55:01 UTC
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

Comment 2 Nir Soffer 2014-07-08 15:05:02 UTC
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?

Comment 3 Ben Marzinski 2014-07-09 20:29:34 UTC
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?

Comment 4 Federico Simoncelli 2014-07-16 09:47:34 UTC
(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"?

Comment 5 Ben Marzinski 2014-07-21 20:19:23 UTC
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.

Comment 6 Nir Soffer 2014-09-16 12:30:11 UTC
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".

Comment 7 Allon Mureinik 2014-09-16 15:53:47 UTC
(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.

Comment 8 Allon Mureinik 2015-04-19 15:43:45 UTC
For RHEV 3.6.0 we'll no longer support RHEL6, so we can move forward with this BZ.

Comment 9 Nir Soffer 2015-05-25 16:17:51 UTC
*** Bug 1223456 has been marked as a duplicate of this bug. ***

Comment 10 Allon Mureinik 2015-06-21 12:13:21 UTC
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.

Comment 11 Elad 2015-08-06 13:20:19 UTC
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

Comment 12 Elad 2015-08-06 13:22:16 UTC
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

Comment 14 errata-xmlrpc 2016-03-09 19:23:06 UTC
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


Note You need to log in before you can comment on or make changes to this bug.