LVM on RedHat 6 does not recognise a LUN resize when paths are managed by DMP

book

Article ID: 100031402

calendar_today

Updated On:

Description

Error Message

No error message was seen

Cause

The failure of LVM to recognise the resize was the omission of the "blockdev --rereadpt" command. Once this command was incorporated into the the procedure, LVM recognised the resize

Resolution

To demonstrate the issue, a 17GB LUN was created and mapped to the host

i) Rescan OS for new device
Ran /usr/bin/rescan-scsi-bus.sh

NEW: Host: scsi2 Channel: 00 Id: 01 Lun: 04
      Vendor: HUAWEI   Model: S5600            Rev: 1
      Type:   Direct-Access                    ANSI SCSI revision: 04
sg14 changed: LU not available (PQual 1)
4 new or changed device(s) found.
        [1:0:0:4]
        [1:0:1:4]
        [2:0:0:4]
        [2:0:1:4]


ii) Check OS sees lun
# lsblk|egrep "sdaa|sdac|sdab|sdad"
sdaa                              65:160  0    17G  0 disk
sdac                              65:192  0    17G  0 disk
sdab                              65:176  0    17G  0 disk
sdad                              65:208  0    17G  0 disk

# fdisk -l|egrep "sdaa|sdac|sdab|sdad"
Disk /dev/sdaa: 18.3 GB, 18253611008 bytes
Disk /dev/sdac: 18.3 GB, 18253611008 bytes
Disk /dev/sdab: 18.3 GB, 18253611008 bytes
Disk /dev/sdad: 18.3 GB, 18253611008 bytes

so, OS sees new 17GB lun fine

iii) Check DMP/VxVM see lun
Volume Manager and DMP already saw the new lun:
# vxdisk list
huawei-s5600-0_20 auto:none       -            -            online invalid

# vxdisk -o size list                                       DEVICE                           SIZE(MB)     GROUP
huawei-s5600-0_20                17408        -

so, DMP/VxVM see lun fine, too

iv) Create an LVM PV and VG

# pvcreate /dev/vx/dmp/huawei-s5600-0_20
  Physical volume "/dev/vx/dmp/huawei-s5600-0_20" successfully created
# vgcreate vg_app3 /dev/vx/dmp/huawei-s5600-0_20
  Volume group "vg_app3" successfully created

v) check of lun at LVM level
# pvs
  /dev/vx/dmp/huawei-s5600-0_20 vg_app3       lvm2 a--   17.00g 17.00g

so, we start with a VG called vg_app3, which is hosted on DMP device: /dev/vx/dmp/huawei-s5600-0_20. It is 17GB big. It will be resized to 19GB

vi) resize lun at array
resized the lun by an additional 2GB

vii) Re-read the LUN at OS level
# blockdev --rereadpt /dev/vx/dmp/huawei-s5600-0_20

viii) Resize the PV
# pvresize /dev/vx/dmp/huawei-s5600-0_20
  Physical volume "/dev/vx/dmp/huawei-s5600-0_20" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

# pvs
  PV                            VG            Fmt  Attr PSize   PFree
  /dev/vx/dmp/huawei-s5600-0_20 vg_app3       lvm2 a--   19.00g 19.00g

so, the lun could be resized without having to resort to the pvresize "setphysicalvolumesize" attribute, simply by using the "blockdev --rereadpt" command.

Issue/Introduction

A LUN containing an LVM volume group was increased in size on the array. The LUN's multipathing was also controlled by DMP. After a rescan by the operating system (OS), LVM failed to recognise the resize. It was initially thought that an issue in DMP prevented LVM acknowledging the resize