topic Re: Logical volume doesn't extend all the luns in the pvg in Operating System - HP-UX

Logical volume doesn't extend all the luns in the pvg

rescuehp17 — Tue, 13 Jun 2017 13:17:03 GMT

When I extend my logical volumes by pvg in the volume group, how come few of my logical volumes only extend to few luns and not all the luns in the volume group set?

For an instance, I have vgtest volume group, which has 11 luns. And I have 11 logical volumes in that volume group vgtest. So i extend like this: for i in 1 2 3 4 5 6 7 8 9 10 11; do lvextend -m 1 /dev/vgtest/lvtest$i pvg2; done...

It worked fine and the mirror worked. But when I lvdisplay on few lvs, i noticed it mirrored to three luns out of 11 luns in the volume group. Is that ok?

Pasted the lvdisplay of lvtest10 below: Text in red color font are the new luns. So now I am planning to unmirror and remove old luns, but need to check if it is okay?

--- Logical volumes ---
LV Name /dev/vgtest/lvtest10
VG Name /dev/vgtest
LV Permission read/write
LV Status available/syncd
Mirror copies 1
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 34816
Current LE 544
Allocated PE 1088
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation non-strict
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/disk/disk2096 37 37
/dev/disk/disk2097 37 37
/dev/disk/disk2098 37 37
/dev/disk/disk2099 37 37
/dev/disk/disk2100 37 37
/dev/disk/disk2101 37 37
/dev/disk/disk2102 37 37
/dev/disk/disk2103 37 37
/dev/disk/disk2104 37 37
/dev/disk/disk2105 37 37
/dev/disk/disk2106 37 37
/dev/disk/disk54 137 137
/dev/disk/disk315 87 87
/dev/disk/disk311 300 300
/dev/disk/disk317 157 157

# cat /etc/lvmpvg

VG /dev/vgtest
PVG pvg1
/dev/disk/disk2096
/dev/disk/disk2097
/dev/disk/disk2098
/dev/disk/disk2099
/dev/disk/disk2100
/dev/disk/disk2101
/dev/disk/disk2102
/dev/disk/disk2103
/dev/disk/disk2104
/dev/disk/disk2105
/dev/disk/disk2106
/dev/disk/disk54
/dev/disk/disk60
PVG pvg2
/dev/disk/disk315
/dev/disk/disk311
/dev/disk/disk317
/dev/disk/disk312
/dev/disk/disk318
/dev/disk/disk313
/dev/disk/disk319
/dev/disk/disk314
/dev/disk/disk320
/dev/disk/disk316
/dev/disk/disk321

Please suggest!

Re: Logical volume doesn't extend all the luns in the pvg

Torsten. — Tue, 13 Jun 2017 13:35:51 GMT

The LVOL is not striped or distributed - this is default behaviour in your case.

...

Schedule parallel

Stripes 0
Stripe Size (Kbytes) 0
Allocation non-strict

...

See

https://community.hpe.com/t5/LVM-and-VxVM/How-to-create-a-Striped-Mirror-logical-volume/td-p/5089862

at the end how to create a mirrored striped LVOL.

Example for striped mirrored LVOL:

# lvdisplay /dev/vgtest/lvol1
--- Logical volumes ---
LV Name /dev/vgtest/lvol1
VG Name /dev/vgtest
LV Permission read/write
LV Status available/syncd
Mirror copies 1
Consistency Recovery MWC
Schedule striped
LV Size (Mbytes) 1024
Current LE 256
Allocated PE 256
Stripes 2
Stripe Size (Kbytes) 64
Bad block on
Allocation strict
IO Timeout (Seconds) default

Re: Logical volume doesn't extend all the luns in the pvg

rescuehp17 — Tue, 13 Jun 2017 13:53:01 GMT

Hi Torsten, thank you for the response.

The allocation is non-strict because I changed it after I mirrored the LV to unmirror. But before I did unmirror, thought to verify in this forum, that is the reason you see allocation as non-strict as I can't unmirror the LV when it is PVG-strict and distributed.

Was like this before mirroring and after mirroring:

Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation PVG-strict/distributed

So, in my case, is it ok or any issue?

Re: Logical volume doesn't extend all the luns in the pvg

TTr — Wed, 14 Jun 2017 11:57:11 GMT

> ...So, in my case, is it ok or any issue?

It depends what you are after. If all you want is to mirror and you don't care how it is done, then it is ok. You should verify by doing "lvdisplay -v /dev/vgXX/lvolYY" for each LVOL and verify that each LE has two PEs (two mirror copies). However from a i/o performance point of view it is not optimal.

If you wanted each volume to be mirrored on a separate disk then you should have run the command separately without the PVG option. Below is from the lvextend man page:

Mirror a logical volume onto a particular physical volume.

           lvextend -m 1 /dev/vg00/lvol3 /dev/dsk/c0t3d0

Re: Logical volume doesn't extend all the luns in the pvg

rescuehp17 — Wed, 14 Jun 2017 12:11:08 GMT

Thank you for the response.

My goal is to migrate from one pvg set of luns to another.

So once I mirror, then I remove the old set of luns(11) by the unmirror procedure.

So, shall I mirror with the following command, instead of pvg?

# lvextend -m 1 /dev/vgtest/lvtest /dev/disk/disk12 /dev/disk/disk13 /dev/disk/disk14 /dev/disk/disk15 /dev/disk/disk16 /dev/disk/disk17 /dev/disk/disk18 /dev/disk/disk19 /dev/disk/disk20 /dev/disk/disk21 /dev/disk/disk22

# lvreduce -m 0 /dev/vgtest/lvtest /dev/disk/disk1 /dev/disk/disk2 /dev/disk/disk3 /dev/disk/disk4 /dev/disk/disk5 /dev/disk/disk6 /dev/disk/disk7 /dev/disk/disk8 /dev/disk/disk9 /dev/disk/disk10 /dev/disk/disk11

In that way I can migrate the luns to have an optimal performance. RIght? Please suggest as I am waiting to implement these change since yesterday.

Re: Logical volume doesn't extend all the luns in the pvg

TTr — Wed, 14 Jun 2017 12:31:30 GMT

>...My goal is to migrate from one pvg set of luns to another.

That does not give us all the details about what you want to do. Do you want to use striping (extend based or not). Do you perhaps want to contain the i/o of each LV into one PV/LUN?

It would also be nice to see what your current VG/LV layout is before you start to mirror.

Re: Logical volume doesn't extend all the luns in the pvg

rescuehp17 — Wed, 14 Jun 2017 13:06:00 GMT

This is the VG:

(root) @/tmp/disks> vgdisplay -v vgtest

--- Volume groups ---

VG Name /dev/vgtest

VG Write Access read/write

VG Status available

Max LV 255

Cur LV 11

Open LV 11

Max PV 255

Cur PV 24

Act PV 24

Max PE per PV 16384

VGDA 48

PE Size (Mbytes) 64

Total PE 6776

Alloc PE 4648

Free PE 2128

Total PVG 2

Total Spare PVs 0

Total Spare PVs in use 0

VG Version 1.0

VG Max Size 255t

VG Max Extents 4177920

--- Logical volumes ---

LV Name /dev/vgtest/lvtest01

LV Status available/syncd

LV Size (Mbytes) 9856

Current LE 154

Allocated PE 308

Used PV 22

LV Name /dev/vgtest/lvtest02

LV Status available/syncd

LV Size (Mbytes) 5632

Current LE 88

Allocated PE 176

Used PV 22

LV Name /dev/vgtest/lvtest03

LV Status available/syncd

LV Size (Mbytes) 13632

Current LE 213

Allocated PE 426

Used PV 13

LV Name /dev/vgtest/lvtest04

LV Status available/syncd

LV Size (Mbytes) 11264

Current LE 176

Allocated PE 352

Used PV 22

LV Name /dev/vgtest/lvtest05

LV Status available/syncd

LV Size (Mbytes) 5632

Current LE 88

Allocated PE 176

Used PV 22

LV Name /dev/vgtest/lvtest06

LV Status available/syncd

LV Size (Mbytes) 5632

Current LE 88

Allocated PE 176

Used PV 22

LV Name /dev/vgtest/lvtest10

LV Status available/syncd

LV Size (Mbytes) 34816

Current LE 544

Allocated PE 1088

Used PV 15

LV Name /dev/vgtest/lvtest11

LV Status available/syncd

LV Size (Mbytes) 30592

Current LE 478

Allocated PE 956

Used PV 16

LV Name /dev/vgtest/lvtest12

LV Status available/syncd

LV Size (Mbytes) 10560

Current LE 165

Allocated PE 330

Used PV 22

LV Name /dev/vgtest/lvtest13

LV Status available/syncd

LV Size (Mbytes) 10560

Current LE 165

Allocated PE 330

Used PV 22

LV Name /dev/vgtest/lvtest14

LV Status available/syncd

LV Size (Mbytes) 10560

Current LE 165

Allocated PE 330

Used PV 22

--- Physical volumes ---

PV Name /dev/disk/disk2096

PV Status available

Total PE 159

Free PE 0

Autoswitch On

Proactive Polling Off

PV Name /dev/disk/disk2097

PV Status available

Total PE 159

Free PE 0

Autoswitch On

Proactive Polling Off

PV Name /dev/disk/disk2098

PV Status available

Total PE 159

Free PE 0

Autoswitch On

Proactive Polling Off

PV Name /dev/disk/disk2099

PV Status available

Total PE 159

Free PE 0

Autoswitch On

Proactive Polling Off

PV Name /dev/disk/disk2100

PV Status available

Total PE 159

Free PE 0

Autoswitch On

Proactive Polling Off

PV Name /dev/disk/disk2101

PV Status available

Total PE 159

Free PE 0

Autoswitch On

Proactive Polling Off

PV Name /dev/disk/disk2102

PV Status available

Total PE 159

Free PE 0

Autoswitch On

Proactive Polling Off

PV Name /dev/disk/disk2103

PV Status available

Total PE 159

Free PE 0

Autoswitch On

Proactive Polling Off

PV Name /dev/disk/disk2104

PV Status available

Total PE 159

Free PE 0

Autoswitch On

Proactive Polling Off

PV Name /dev/disk/disk2105

PV Status available

Total PE 159

Free PE 0

Autoswitch On

Proactive Polling Off

PV Name /dev/disk/disk2106

PV Status available

Total PE 159

Free PE 0

Autoswitch On

Proactive Polling Off

PV Name /dev/disk/disk54

PV Status available

Total PE 319

Free PE 0

Autoswitch On

Proactive Polling On

PV Name /dev/disk/disk60

PV Status available

Total PE 319

Free PE 63

Autoswitch On

Proactive Polling On

PV Name /dev/disk/disk315

PV Status available

Total PE 399

Free PE 0

Autoswitch On

Proactive Polling On

PV Name /dev/disk/disk311

PV Status available

Total PE 399

Free PE 0

Autoswitch On

Proactive Polling On

PV Name /dev/disk/disk317

PV Status available

Total PE 399

Free PE 0

Autoswitch On

Proactive Polling On

PV Name /dev/disk/disk312

PV Status available

Total PE 399

Free PE 0

Autoswitch On

Proactive Polling On

PV Name /dev/disk/disk318

PV Status available

Total PE 399

Free PE 265

Autoswitch On

Proactive Polling On

PV Name /dev/disk/disk313

PV Status available

Total PE 399

Free PE 300

Autoswitch On

Proactive Polling On

PV Name /dev/disk/disk319

PV Status available

Total PE 399

Free PE 300

Autoswitch On

Proactive Polling On

PV Name /dev/disk/disk314

PV Status available

Total PE 399

Free PE 300

Autoswitch On

Proactive Polling On

PV Name /dev/disk/disk320

PV Status available

Total PE 399

Free PE 300

Autoswitch On

Proactive Polling On

PV Name /dev/disk/disk316

PV Status available

Total PE 399

Free PE 300

Autoswitch On

Proactive Polling On

PV Name /dev/disk/disk321

PV Status available

Total PE 399

Free PE 300

Autoswitch On

Proactive Polling On

--- Physical volume groups ---

PVG Name pvg1

PV Name /dev/disk/disk2096

PV Name /dev/disk/disk2097

PV Name /dev/disk/disk2098

PV Name /dev/disk/disk2099

PV Name /dev/disk/disk2100

PV Name /dev/disk/disk2101

PV Name /dev/disk/disk2102

PV Name /dev/disk/disk2103

PV Name /dev/disk/disk2104

PV Name /dev/disk/disk2105

PV Name /dev/disk/disk2106

PV Name /dev/disk/disk54

PV Name /dev/disk/disk60

PVG Name pvg2

PV Name /dev/disk/disk315

PV Name /dev/disk/disk311

PV Name /dev/disk/disk317

PV Name /dev/disk/disk312

PV Name /dev/disk/disk318

PV Name /dev/disk/disk313

PV Name /dev/disk/disk319

PV Name /dev/disk/disk314

PV Name /dev/disk/disk320

PV Name /dev/disk/disk316

PV Name /dev/disk/disk321

(root) @/tmp/disks>

GOAL:

--- Physical volume groups ---
PVG Name pvg1
PV Name /dev/disk/disk2096
PV Name /dev/disk/disk2097
PV Name /dev/disk/disk2098
PV Name /dev/disk/disk2099
PV Name /dev/disk/disk2100
PV Name /dev/disk/disk2101
PV Name /dev/disk/disk2102
PV Name /dev/disk/disk2103
PV Name /dev/disk/disk2104
PV Name /dev/disk/disk2105
PV Name /dev/disk/disk2106
PV Name /dev/disk/disk54
PV Name /dev/disk/disk60

PVG Name pvg2
PV Name /dev/disk/disk315
PV Name /dev/disk/disk311
PV Name /dev/disk/disk317
PV Name /dev/disk/disk312
PV Name /dev/disk/disk318
PV Name /dev/disk/disk313
PV Name /dev/disk/disk319
PV Name /dev/disk/disk314
PV Name /dev/disk/disk320
PV Name /dev/disk/disk316
PV Name /dev/disk/disk321

PVG1 = old set of luns

PVG2 = new set of luns

My goal is to migrate the data from pvg1 to pvg2 set of luns. So I was planning to migrate this way:

Once the pvg2 was extended to the volume group, then I mirror the LVS and then unmirror while removing old set of luns. Please suggest the best option to do it, while all is online.

Re: Logical volume doesn't extend all the luns in the pvg

Torsten. — Wed, 14 Jun 2017 13:24:13 GMT

What array model (new/old) do we talk about?

For most modern arrays there is no benefit to use multiple LUNs instead of a single LUN.

Re: Logical volume doesn't extend all the luns in the pvg

rescuehp17 — Wed, 14 Jun 2017 13:35:27 GMT

That is what I thought, but as I inherited this server and not known the reason behind, I kept the same number of luns in the new array set too....old is CX4 and new is VNX. Please let me know.

Re: Logical volume doesn't extend all the luns in the pvg

Torsten. — Wed, 14 Jun 2017 13:40:33 GMT

I don't know the arrays in detail, so I cannot tell, sorry.

For older arrays with a fixed number of disks in a RAID and a single owner controller it was a good method to use different LUNs, but for any kind of virtual arrays using many disks for a single LUN anyway and maybe many active controllers for a single LUN you would create a single LUN only (as an example HPE MSA2000G3 vs. 3PAR or XP7).

Re: Logical volume doesn't extend all the luns in the pvg

rescuehp17 — Wed, 14 Jun 2017 13:54:00 GMT

No problem. I will keep the same set of luns, just in case.

But the question remains, why few LVs doesn't extend to all 11 disks? Is it okay to have the data in couple luns of the PVG before I unmirror and remove the old set of the luns(PVG)?

Thank you!

Re: Logical volume doesn't extend all the luns in the pvg

Torsten. — Wed, 14 Jun 2017 14:11:41 GMT

You need to switch back to LE based distribution policy, so the LE will be allocated to each disk one by one.

Re: Logical volume doesn't extend all the luns in the pvg

rescuehp17 — Wed, 14 Jun 2017 14:16:41 GMT

How is that? I mean, how can I do that? As said, When I mirrored, the Allocation policy of the LVs were PVG-strict/distributed. I was about to unmirror that is the reason I turned those allocation policies off.

Re: Logical volume doesn't extend all the luns in the pvg

TTr — Wed, 14 Jun 2017 14:22:41 GMT

We still don't know how the LVOLs are laid out on the old LUNs. This would be in the output of eleven "lvdisplay -v /dev/vgxx/lvolYY" commands. You can run them and create a table summary rather than posting them all.

Your mirroring right now is using 5.5 out of the 11 new LUNs.

I would mirror each LVOL in a separate new LUN like I posted above and forget about striping. If the array has some kind of backend stripping and virtualization as Torsten mentioned, you should not have any i/o issues.

Re: Logical volume doesn't extend all the luns in the pvg

Torsten. — Wed, 14 Jun 2017 14:38:34 GMT

PVG-strict/distributed

is what you want.

PVG strict means LVOLs are mirrored from one PVG to the other.

distributed means

PE1 to disk1

PE2 to disk2

PE3 to disk3

...

Re: Logical volume doesn't extend all the luns in the pvg

rescuehp17 — Wed, 14 Jun 2017 14:46:33 GMT

Yes, it was PVG-strict/distributed, when I mirrored