VG Recreation with Modified LVM Parms without Need to Copy Data

[Ralph Grothe]

Hello,

I reached the upper limit of max PVs according to the vg's configuration but need to further extend (i.e. attach further disks).

see

# vgdisplay vgz01
--- Volume groups ---
VG Name /dev/vgz01
VG Write Access read/write
VG Status available, exclusive
Max LV 255
Cur LV 25
Open LV 25
Max PV 16
Cur PV 16
Act PV 16
Max PE per PV 25000
VGDA 32
PE Size (Mbytes) 8
Total PE 76317
Alloc PE 70901
Free PE 5416
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0


# vgdisplay -v vgz01|awk '/PV Name/{print$NF}'|wc -w
16


As you can evaluate from the above vgdisplay output the vg currently has approx. 553 GB allocated, and I definitely urge to avoid copying this bulk of data.

Thus, I hope that there is a method similar to a new vgcreate with e.g. "-p 64", and subsequent vgexport of old vgz01 and vgimport into new.

I know that this won't work with vgex/import,
but I'm sure you could gather my intentions since all I want to modify is minute LVM metadata (viz. max No. of PVs per VG) without the need to touch or shift any stored application data whatsoever.

Rgds.
Ralph

[Bernhard Mueller · Accepted solution]

Ralph (sorry for mis-spelling your name last time),

I really think this is not feasible, similar to the issue that you cannot change MAX PE per PV;

because the VGRA including the VGDA, which in turn includes the PV entries array would have to change in size. This in turn would require to move the data area on the disk a few blocks further...

Regards,
Bernhard

[Marco Santerre]

Ralph,

I'll have to comply with the other answer here as I have been through what you are going through right now. There is no "easy" way to change the Max PV parms in the VG.

The only way I've known (and that I've gone through) is create a new VG and copy the data in it.

[Stuart Abramson_2]

Ralph:

You can't do it.

But, let me ask you a question:

..Why do you need to add more PVs to THIS VG?

..Why don't you just create a 2nd VG and put the new LVs in the 2nd VG?

..You could call the first VG vgora1 and have oradata01-25 in the first VG, and call the 2nd VG vgora2, and call the LVs oradata26-50 in the 2nd VG.

Oracle, for example, will just exactly the same from 2 VGs as he does from 1 VG. He doesn't care about VGs, or LVs, only FileSystems.

[Ralph Grothe]

Bernhard, Marco,

I have feared this already but wanted to make sure whether there weren't some (unofficial?) quirk to get done however.

Stuart,

yes basically you are to agree to.
I also would handle it this way.
The reasons that somewhat were opposing were that

a) the vg is a cluster shared vg, and further vgs would require a shutdown of the cluster because so far its configuration only knows the mentioned one:

# cmgetconf -c ipv01|grep ^VOL
VOLUME_GROUP /dev/vgz01

b) for some (awkward) organizational reasons the DBAs want to have it in one single vg.

But ultimatively I think I cannot avoid the copying anyway because the disks are from various disk arrays and our SAN admins want to reorganize the disk per application/customer organization sooner or later.

[Bernhard Mueller]

Ralph,

if you can win over the DBA and ignore b)

then we can talk about a):
You can add a new VG with the cluster up and running, no problem. Basically you just need to bring the package down.

If bringing down the package is an issue, it even should work without bringing the package down. You just need to do manually (vgchange, mount etc) what you add to the package script... (of course you should double-check your changes, no triple-check them!)

Regards,
Bernhard