Function multipath_resize_map return "invalid map name" when extending volume

Bug #1609753 reported by Yafei Yu
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
os-brick
Fix Released
Undecided
Rajat Dhasmana

Bug Description

OS Version:
# rpm -qa |grep release
centos-release-7-0.1406.el7.centos.2.4.x86_64

When extending volume, if multipath device exist, cmd "multipathd resize map mpath_id" is used to force the multipath daemon to update it's
size information a particular multipath device. But cmd "multipathd resize map mpath_id" returns "invalid map name".
Here is a test:
(1) Resize the physical device ## use whatever method your SAN uses to resize the physical device (My test volume:30G -->35G)
(2) Rescan sd device: echo 1 > /sys/bus/scsi/drivers/sd/device_id/rescan
(3) # blockdev --getsize64 /dev/disk/by-id/dm-uuid-mpath-3500500d4315ac777
32212254720
(4)# multipathd resize map 3500500d4315ac777
invalid map name
(5)# blockdev --getsize64 /dev/disk/by-id/dm-uuid-mpath-3500500d4315ac777
32212254720
(6)# multipathd resize map mpathduk
ok
(7)# blockdev --getsize64 /dev/disk/by-id/dm-uuid-mpath-3500500d4315ac777
37580963840

So, we should use mpath name insead of mpath id in function multipath_resize_map.

Yafei Yu (yu-yafei)
Changed in os-brick:
assignee: nobody → yuyafei (yu-yafei)
Revision history for this message
Sean McGinnis (sean-mcginnis) wrote : Bug Assignee Expired

Unassigning due to no activity for > 6 months.

Changed in os-brick:
assignee: yuyafei (yu-yafei) → nobody
Revision history for this message
Krzysztof Pawlowski (krzysztof.pawlowski) wrote :

In my case disabling user friendly names in multipath.conf solved the issue:

defaults {
        user_friendly_names no
        find_multipaths yes
}

Gorka Eguileor (gorka)
tags: added: extend multipath
Changed in os-brick:
assignee: nobody → Rajat Dhasmana (whoami-rajat)
Revision history for this message
Rajat Dhasmana (whoami-rajat) wrote :
Changed in os-brick:
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (master)

Reviewed: https://review.opendev.org/c/openstack/os-brick/+/889168
Committed: https://opendev.org/openstack/os-brick/commit/75714711f2631dbba19750c55a7b049bb07da379
Submitter: "Zuul (22348)"
Branch: master

commit 75714711f2631dbba19750c55a7b049bb07da379
Author: Rajat Dhasmana <email address hidden>
Date: Fri Jul 21 10:26:11 2023 +0000

    Fix multipath resize map with friendly names

    When multipath is enabled and friendly names are ON and we try
    to extend a volume, we pass the SCSI WWID to the multipath_resize_map
    method which is not correct.

    There are 2 things we can pass to the multipathd resize map command:

    1) Multipath device (eg: dm-0)
    2) Alias (eg: mpath1) or UUID (eg: 36005076303ffc56200000000000010aa)

    The value should be an alias (mpath1) when friendly names are ON
    and UUID (36005076303ffc56200000000000010aa) when friendly names
    are OFF. However, we only pass the UUID irrespective of the value
    set for friendly names.

    This patch passes the multipath device path (to multipathd resize
    map command) which is the real path of the multipath device (/dev/dm-*).
    This fixes the issue as it passes the same value irrespective of if
    the friendly names are ON or OFF.

    -> self.multipath_resize_map(os.path.realpath(mpath_device))

    (Pdb) mpath_device
    '/dev/disk/by-id/dm-uuid-mpath-3600140522774ce73be84f9cb9537e0c9'

    (Pdb) os.path.realpath(mpath_device)
    '/dev/dm-5'

    Closes-Bug: 1609753
    Change-Id: I1c60af19c2ebaa9de878cd07cfc0077c5ea56fe3

Changed in os-brick:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/os-brick 6.4.0

This issue was fixed in the openstack/os-brick 6.4.0 release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.