error when running vgmodify

[derek b smith_1]

Hi again!

I get this error:
I ran vgmodify b/c the EMC lun was expanded to 150Gb from 30Gb.

# vgmodify /dev/vg30

meta data here....
vgmodify: Invalid LVMREC on Physical Volume /dev/rdsk/c32t1d1

I looked and looked and referenced "when good disks go bad" with no success.

I removed the pvs, then the vg, then ran
dd if=/dev/zero of=/dev/rdsk/c32t1d1 bs=1024 count=1024

then verified using dump_lvmtab -s which says
VG[003] VGID:00000000 4bd1aed0 (@0x00e136) pvnum:4 state:0x0000 /dev/vg30
(000) VGID:00000000 4bd1aed0 PVID:00000000 4bd1ad88 /dev/rdsk/c32t1d1
(001) VGID:00000000 4bd1aed0 PVID:00000000 4bd1ad88 /dev/rdsk/c34t1d1
(002) VGID:00000000 4bd1aed0 PVID:00000000 4bd1ad88 /dev/rdsk/c36t1d1
(003) VGID:00000000 4bd1aed0 PVID:00000000 4bd1ad88 /dev/rdsk/c38t1d1

# ll /dev/vg*/group
crw-r----- 1 root sys 64 0x000000 Jun 6 2008 /dev/vg00/group
crw-r--r-- 1 root sys 64 0x010000 Jun 18 2008 /dev/vg01/group
crw-r--r-- 1 root sys 64 0x020000 Jan 31 2009 /dev/vg20/group
crw-r--r-- 1 root sys 64 0x030000 Apr 23 10:28 /dev/vg30/group

and after recreating vg30, I still see this error.

This is a new vg with new EMC disks that will house encrypted data and I do not have a saved map file.

pleas help!

thank you

[Raj D. · Accepted solution]

Derek,

Hi, What you are trying to achieve here:
I understand you have got one lun (extended 30GB to 150GB , and want to create a vg. Why do you need vgmodify. vgmodify is used to modify the VG parameters in case of if it is hitting the limit.

Can you not able to recreate the vg , as this is new lun and new vg:

Please try the below to create the vg:
Keep mapfile of existing:

# vgdisplay -v vg30 > vg30.old.txt
# vgexport -v -s -m v30.map vg30
# pvcreate -f /dev/rdsk/c32t1d1

# mkdir /dev/vg30
# mknod /dev/vg30 c 64 0x300000
# vgcreate -p 255 -s 64 -e 20000 vg30 /dev/rdsk/c32t1d1
# vgchange -a y vg30
# vgdisplay vg30


Please post further,
Hth,
Raj.

[TTr]

Why do you need to run vgmodify if you can remove and recreate vg30 and you are dd-ing the LUN?

[Raj D.]

correction:

(in the mknod group entry corrected).
# mknod /dev/vg30/group c 64 0x300000

[derek b smith_1]

I need to run vgmodify b/c the LUN was expanded to 150Gb. :)

# vgcreate -p 255 -s 64 -e 20000 /dev/vg30 /dev/dsk/c32t1d1

# vgdisplay vg30
--- Volume groups ---
VG Name /dev/vg30
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 0
Open LV 0
Max PV 255
Cur PV 1
Act PV 1
Max PE per PV 20000
VGDA 2
PE Size (Mbytes) 64
Total PE 538
Alloc PE 0
Free PE 538
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

vgextend vg30 /dev/dsk/c34t1d1
vgextend vg30 /dev/dsk/c36t1d1
vgextend vg30 /dev/dsk/c38t1d1

--- Physical volumes ---
PV Name /dev/dsk/c32t1d1
PV Name /dev/dsk/c34t1d1 Alternate Link
PV Name /dev/dsk/c36t1d1 Alternate Link
PV Name /dev/dsk/c38t1d1 Alternate Link
PV Status available
Total PE 538
Free PE 538
Autoswitch On
Proactive Polling On

# diskinfo /dev/rdsk/c32t1d1
SCSI describe of /dev/rdsk/c32t1d1:
vendor: EMC
product id: SYMMETRIX
type: direct access
size: 35356800 Kbytes
bytes per sector: 512

root@
# echo 64*538|bc
34432
vg30 only shows 35Gb
sam is consistent.

# powermt display dev=all
Symmetrix ID=000190301012
Logical device ID=024E
state=alive; policy=SymmOpt; priority=0; queued-IOs=0
==============================================================================
---------------- Host --------------- - Stor - -- I/O Path - -- Stats ---
### HW Path I/O Paths Interf. Mode State Q-IOs Errors
==============================================================================
32 0/0/8/1/0.110.124.0.0.1.1 c32t1d1 FA 1dA active alive 0 3
34 0/0/10/1/0.110.124.0.0.1.1 c34t1d1 FA 1dA active alive 0 1
36 1/0/8/1/0.110.124.0.0.1.1 c36t1d1 FA 16dA active alive 0 1
38 1/0/10/1/0.110.124.0.0.1.1 c38t1d1 FA 16dA active alive 0 1

[TTr]

> I need to run vgmodify b/c the LUN was expanded to 150Gb

Based on what you have attempted so far, yut you are treating this LUN as a new disk in your LVM config. vgmodify is needed *only* if you expand a LUN that is already configured and in use in a volume group on the server.

No need to run vgmodify here. Configure it as a new disk as indicated above.

[derek b smith_1]

It originally was apart of a vg, a vg that I had free-reign on. vgmodify never worked. So I decided to recreate it and now it does not see it as 150VG. Why?

[Patrick Wallek]

I think at this point vgmodify isn't the problem. The problem is that the LUN was extended and HP-UX is still seeing it at the old size, which prior to 11.31 I believe, is expected.

What version of HP-UX are you running?

[Raj D.]

Well, if you can see 150 GB size in diskinfo then the lun is presented correctly and visible correctly to the os:

What is the output of :
# diskinfo -v /dev/rdsk/c32t1d1


Hth,
Raj.

[TTr]

> dd if=/dev/zero of=/dev/rdsk/c32t1d1 bs=1024 count=1024

Is this exactly what you typed? This writes 1024 bytes only so the total written to the disk is 1k. Change the block size to bs=1024k and count=100000

You could also try pvremove.

Do you have any proof that the LUN was enlarged in the EMC?

[derek b smith_1]

yeah tried all these actions b4 posting, but thanks for hanging in there!

# diskinfo /dev/rdsk/c32t1d1
SCSI describe of /dev/rdsk/c32t1d1:
vendor: EMC
product id: SYMMETRIX
type: direct access
size: 35356800 Kbytes
bytes per sector: 512

Here is the SAN guy's explanation:

# cat file.txt
add dev 22f:235 to meta 24e,
protect_data=FALSE;
# ./symconfigure -sid 1012 -v -f file.txt prepare -nop
# ./symconfigure -sid 1012 -v -f file.txt commit -nop


Basically I took the existing lun, 33 or so GB that was initially made up of 2 16gb hypers. Unmasked the volume from the host, then ran the above command that tells the DMX to add the devices 22f-235 to the 24e meta device. We were told that there was not any data that needed to be saved, so we did not need to pass the protect_data flag as true, nor did we need to have a bcv_meta_head in place to temporarily hold the data while the lun was being restriped, as the data was being destroyed in this lun expansion.

[Steven E. Protter]

Shalom,

There is an approach problem here.

People need more space, they think, lets just expand the LUN.

HP-UX and many OS have a hard time dealing with that, at least without a boot cycle.

Here is what we do here on Toledo:

A 300 GB lun actually consists of 10 30 GB LUNS. When we need more space, we add another 30 GB LUN.

Then we vgextend, lvextend fsadm to recognize the new disks space.

SEP

[derek b smith_1]

SEP, isn't that the point of vgmodify? :)


# vgmodify /dev/vg30

Current Volume Group settings:
Max LV 255
Max PV 255
Max PE per PV 20000
PE Size (Mbytes) 64
VGRA Size (Kbytes) 41568
vgmodify: Invalid LVMREC on Physical Volume /dev/rdsk/c32t1d1
root@john [/]
# uname -a
HP-UX john B.11.23 U 9000/800 john unlimited-user license

[derek b smith_1]

we have a decru datafort that sits between the hosts and the storage that requires encryption. We unmasked the disk from the host at the datafort layer, and removed all instances of luns from powerpath, then LVM then rescanned to verify all was gone and it was.
then remasked, then ioscan, powermt config and now:

diskinfo /dev/rdsk/c32t1d1
SCSI describe of /dev/rdsk/c32t1d1:
vendor: EMC
product id: SYMMETRIX
type: direct access
size: 159105600 Kbytes
bytes per sector: 512

So I still need to know is something wrong with vgmodify or I need a patch?
I obviously cannot do this on production LUNS and was counting on vgmodify.

I have this patch:

# swlist -a state -l patch |grep PHCO_38717
PHCO_38717.LVM-ENG-A-MAN configured
PHCO_38717.LVM-MIRROR-RUN configured
PHCO_38717.LVM-RUN configured

[Patrick Wallek]

vgmodify has absolutely NOTHING to do with how the OS sees the LUNs it is presented. vgmodify allows the VG to see a larger LUN once the OS is aware that the LUN is larger.

There are somethings that can be done on later versions of HP-UX to allow the OS to use resized LUNs more easily. But, the OS must realize that the LUN is larger before anything else can happen.

[derek b smith_1]

Well per the doc all this is possible.
I can always call support!