Long time ago, when I studied the Veritas LVM, I knew the PVG term which meant physical volume group and the physical volumes in the same PVG were from the same SAN or same disk. Usually there is a single point of failure of the same PVG and when we build mirror or other soft arrays, we have to distribute the segment on different PVGs not different PVs.
I tried to find the similar concept on AIX many times and failed always until last day I got a similar concept named mirror pool here.
Last day I had to add four LUNs from two SAN devices to a VG and extent the current jfs2 filesystem. There were already more than ten PVs in the VG so I had to make sure the LP mirrors of every LV were located on different SAN devices. More important, when the customer extent such filesystems by themselves, such rule should be followed automatically.
So to archive the goal, I had to assign all the current PVs to different mirror pools then change all the LVs to user different mirror pools for different copies with below commands:
chpv -p PoolA hdisk2 chpv -p PoolA hdisk3 chpv -p PoolA hdisk4 chpv -p PoolA hdisk5 chpv -p PoolB hdisk12 chpv -p PoolB hdisk13 chpv -p PoolB hdisk14 chpv -p PoolB hdisk15 extendvg -p PoolA sapdata hdisk6 hdisk7 extendvg -p PoolB sapdata hdisk16 hdisk17 chlv -m copy1=PoolA -m copy2=PoolB fsdata1 chlv -m copy1=PoolA -m copy2=PoolB fsdata2
Then I extended the filesystem fsdata1 and fsdata2 and verified all the new PPs were on different mirror pools.
Note: I run the 'reorgvg sapdata fsdata1' to correct the previous existing wrong allocation of PPs while it lasted several hours and finally I had to cancel it manually. The size of fsdata1 is about 1.6T.
The above experience let me know the weakness of mirror pool. When I run reorgvg the fix allocation issue of LV, it will make sure the first PP is from PoolA and the second one is from PoolB, while in fact I just want to make sure both PPS are from different mirror pools.
