Tuesday, 9 August 2022


LVM Errors when One Disk is Mapped from one VIOS to Multiple LPARs:


A disk shared to an LPAR from a VIOS can have three mapping configurations:


1.  One-to-one: The disk is mapped directly from a VIOS to one LPAR

2.  One-to-many by design:  A disk is intentionally shared between multiple LPARs in a concurrent environment

3.  One-to-many incorrectly: A disk is inadvertently shared from a VIOS to multiple LPARs


When a disk is inadvertently mapped to multiple LPARs, LVM inconsistencies can occur.  Below is an example of incorrectly mapping one disk to multiple LPARs and the resulting errors.


1.  Map the disk from VIOS --> vhost0


$ mkvdev -vdev hdisk15 -vadapter vhost0

$ lsmap -vadapter vhost0

SVSA            Physloc                                      Client Partition ID

--------------- -------------------------------------------- ------------------

vhost0          U9117.MMA.1010A00-V2-C12                     0x0000000a


VTD                   vtscsi12

Status                Available

LUN                   0x8200000000000000

Backing device        hdisk15

Physloc               U789D.001.DQDYKHP-P1-C1-T1-W500507680B21683C-L0

Mirrored              false


2.  Map the disk from VIOS --> vhost1


$ mkvdev -f -vdev hdisk15 -vadapter vhost1

$ lsmap -vadapter vhost1

SVSA            Physloc                                      Client Partition ID

--------------- -------------------------------------------- ------------------

vhost1          U9117.MMA.1010A00-V2-C13                     0x0000000b


VTD                   vtscsi13

Status                Available

LUN                   0x8200000000000000

Backing device        hdisk15

Physloc               U789D.001.DQDYKHP-P1-C1-T1-W500507680B21683C-L0

Mirrored              false


Now the disk is shared between LPAR1 and LPAR2 and the PVIDs are 00c10a003757f29e.


LPAR1 (vhost0):

(lpar1-vhost0)# lspv

hdisk0          00c10a00e7970f11                    rootvg          active

hdisk1          00c10a003757f29e                    None


LPAR2 (vhost1):

(lpar2-vhost1)# lspv

hdisk0          00c10a000bf5ee59                    rootvg          active

hdisk1          00c10a003757f29e                    None


3.  Create a VG on hdisk1 on LPAR1 (vhost0)


(lpar1-vhost0)# mkvg hdisk1

(lpar1-vhost0)# lspv

hdisk0          00c10a00e7970f11                    rootvg          active

hdisk1          00c10a003757f29e                    vg00            active


4. Change the PVID for hdisk1 on LPAR2 (vhost1)


(lpar2-vhost1)# chdev -l hdisk1 -a pv=clear

(lpar2-vhost1)# chdev -l hdisk1 -a pv=yes

(lpar2-vhost1)# lspv

hdisk0          00c10a000bf5ee59                    rootvg          active

hdisk1          00c10a0037b59fe5                    None


5.  Varyonvg error


At this point, LVM information on LPAR1 assumes the disk PVID is 00c10a003757f29e, but LPAR2 has changed the PVID to 00c10a0037b59fe5.


When we try to varyoff then varyon the volume group on LPAR1, it can not find 00c10a003757f29e.


(lpar1-vhost0)# varyoffvg vg00

(lpar1-vhost0)# varyonvg vg00

0516-013 varyonvg: The volume group cannot be varied on because

        there are no good copies of the descriptor area.


6. Importvg error


From LPAR2, if we try to import the volume group we received the follow error.


(lpar2-vhost1)# lspv

hdisk0          00c10a000bf5ee59                    rootvg          active

hdisk1          00c10a0037b59fe5                    None

(lpar2-vhost1)# importvg hdisk1

0516-1939 : PV identifier not found in VGDA.

0516-780 importvg: Unable to import volume group from hdisk1.


7.  Root cause for varyonvg and importvg errors


Since the LPARs share the disk but have their own ODM entries, we can see the discrepancy.


PVID

ODM On Disk

lpar1-vhost0 00c10a003757f29e 00C10A00 37B59FE5

lpar2-vhost1 00c10a0037b59fe5 00C10A00 37B59FE5

The PVID in the ODM must match the PVID in the LVM metadata.  If changes are made to a disk mapped to multiple LPARs, the PVIDs in the ODM may not match the PVIDs in the LVM metadata.


If you experience the errors cited, or similar errors referencing the VGDA, please contact IBM support to correct the LVM inconsistencies.  Incorrect attempts at repairing LVM metadata may result in data loss or system instability.

No comments:

Post a Comment