Extendvg Problem

[ereshatezer]

Hello @ll,

I have a very strange extendvg problem.
I inherited a system and now I would like to add new PV to a VG, but I am unable to do it.

I have run out of ideas. Any idea?

The error message is the following:
0516-792 extendvg: Unable to extend volume group.

Here are some details:


#################################
--> lsvg -p B02sapvg
B02sapvg:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdisk2 active 443 0 00..00..00..00..00
hdisk3 active 760 6 00..00..00..00..06
hdisk4 active 799 0 00..00..00..00..00
hdisk5 active 799 0 00..00..00..00..00
#################################

hdisk2 000db5bf111d3b17 B02sapvg active
hdisk3 000db5bf12fa6991 B02sapvg active
hdisk4 000db5bf539c77dc B02sapvg active
hdisk5 00579aaa441519ff B02sapvg active
hdisk6 000db5bf111d3b17 B02sapvg active
hdisk7 000db5bf12fa6991 B02sapvg active
hdisk8 000db5bf539c77dc B02sapvg active
hdisk9 00579aaa441519ff B02sapvg active
hdisk10 00ce7b2f21b2011c None
hdisk11 00ce7b2f21b2011c None

###
There are ghost disks, so do not be surprised on the output of lspv as I was..
###
-> odmget -q parent=fscsi0 CuDv |grep name
name = "hdisk2"
name = "hdisk3"
name = "hdisk4"
name = "hdisk5"
name = "hdisk10"
#################################
--> odmget -q parent=fscsi1 CuDv |grep name
name = "hdisk6"
name = "hdisk7"
name = "hdisk8"
name = "hdisk9"
name = "hdisk11"
#################################
fcs0 Available 05-08 FC Adapter
fcs1 Available 07-08 FC Adapter
#################################

Followings were tried.
- WWN numbers are OK.
- pvids were clear, but extendvg didn't work afterwards.
- extendvg -f was tried
- ODM, VGDA corruption was checked.

 

[plamb]

I believe your problem is you need 1 pp free on each disk so the VGDA of new disks can be added to exsisting disks to reflect additional added storage. Y

 

[ereshatezer]

Unfortunately 1pp free didn't help. After at least 1PP were free on each disk in the VG, extendvg still does not work.

--> odmget -q name="hdisk10" CuDv

CuDv:
name = "hdisk10"
status = 1
chgstatus = 2
ddins = "scsidisk"
location = "05-08-01"
parent = "fscsi0"
connwhere = "5"
PdDvLn = "disk/fcp/Hitachi"

 

[khalidaaa]

Well, from the output of the odm i can see that this disk is available as shows by the status!?!

so was there any hope from reading the disk's VGDA? (lqueryvg -p hdisk10 -At)

if its working with testvg then it should work with B02sapvg?!?

Is there any data in the hdisk10 and 11?

 

[p5wizard]

Couple of questions:

How much free space in root filesystem?

Are the disks that are in your B02sapvg now from the same SAN server? All the same (type) Hitachi box?

Also please go through this test again:
First create "testvg" on hdisk10 only, then post output of
# lsvg B02sapvg (was already posted)
# lspv hdisk2
# lsvg testvg
# lspv hdisk10



HTH,

p5wizard

 

[ereshatezer]

11:44:16_B02_root@HOSTNAME(0) /
--> lsvg B02sapvg
VOLUME GROUP: B02sapvg VG IDENTIFIER: 000db5bf00004c00000000f297d22d50
VG STATE: active PP SIZE: 64 megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 2801 (179264 megabytes)
MAX LVs: 256 FREE PPs: 6 (384 megabytes)
LVs: 21 USED PPs: 2795 (178880 megabytes)
OPEN LVs: 21 QUORUM: 1
TOTAL PVs: 4 VG DESCRIPTORS: 4
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 4 AUTO ON: yes
MAX PPs per VG: 32512
MAX PPs per PV: 1016 MAX PVs: 32
LTG size: 128 kilobyte(s) AUTO SYNC: no
HOT SPARE: no BB POLICY: relocatable
11:44:27_B02_root@HOSTNAME(0) /
--> lspv hdisk2
PHYSICAL VOLUME: hdisk2 VOLUME GROUP: B02sapvg
PV IDENTIFIER: 000db5bf111d3b17 VG IDENTIFIER 000db5bf00004c00000000f297d22d50
PV STATE: active
STALE PARTITIONS: 0 ALLOCATABLE: yes
PP SIZE: 64 megabyte(s) LOGICAL VOLUMES: 2
TOTAL PPs: 443 (28352 megabytes) VG DESCRIPTORS: 1
FREE PPs: 0 (0 megabytes) HOT SPARE: no
USED PPs: 443 (28352 megabytes) MAX REQUEST: ???????
FREE DISTRIBUTION: 00..00..00..00..00
USED DISTRIBUTION: 89..89..88..88..89
11:45:10_B02_root@HOSTNAME(0) /
--> lsvg testvg
VOLUME GROUP: testvg VG IDENTIFIER: 00ce7b2f00004c000000010d5e76a19d
VG STATE: active PP SIZE: 64 megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 799 (51136 megabytes)
MAX LVs: 256 FREE PPs: 799 (51136 megabytes)
LVs: 0 USED PPs: 0 (0 megabytes)
OPEN LVs: 0 QUORUM: 2
TOTAL PVs: 1 VG DESCRIPTORS: 2
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 1 AUTO ON: yes
MAX PPs per VG: 32512
MAX PPs per PV: 1016 MAX PVs: 32
LTG size (Dynamic): 256 kilobyte(s) AUTO SYNC: no
HOT SPARE: no BB POLICY: relocatable
11:45:52_B02_root@HOSTNAME(0) /
--> lspv hdisk10
PHYSICAL VOLUME: hdisk10 VOLUME GROUP: testvg
PV IDENTIFIER: 00ce7b2f5a3ac069 VG IDENTIFIER 00ce7b2f00004c000000010d5e76a19d
PV STATE: active
STALE PARTITIONS: 0 ALLOCATABLE: yes
PP SIZE: 64 megabyte(s) LOGICAL VOLUMES: 0
TOTAL PPs: 799 (51136 megabytes) VG DESCRIPTORS: 2
FREE PPs: 799 (51136 megabytes) HOT SPARE: no
USED PPs: 0 (0 megabytes) MAX REQUEST: ???????
FREE DISTRIBUTION: 160..160..159..160..160
USED DISTRIBUTION: 00..00..00..00..00




root FS has enough freespace (over 100 MB...)

 

[p5wizard]

rephrased:

Are the disks that are in your B02sapvg now and the new disk from the same SAN server? All the same (type) Hitachi box?


HTH,

p5wizard

 

[ereshatezer]

yes.

 

[ITEng013]

Have you exported testvg so that hdisk10 is no longer part of that volume group?

 

[p5wizard]

what does lsattr -E -l hdisk10 show? (max_transfer attribute)

I see a difference in LTG size in B02sapvg and testvg.

You might want to try to adjust max_transfer of hdisk10 to match the LTG size of B02sapvg - although it indicates a max size and I assume it is now 0x40000 (=> LTG 256K of testvg) and B02sapvg expects it to be at least 0x2000 (LTG is 128K)

chdev -l hdisk10 -a max_transfer=0x20000

then try extendvg again.


HTH,

p5wizard

 

[ereshatezer]

hdisk10 has no max_transfer attribute.

--> lsattr -El hdisk10
clr_q no Device CLEARS its Queue on error True
location Location Label False
lun_id 0x4000000000000 Logical Unit Number ID False
pvid 00ce7b2f68ceacc50000000000000000 Physical Volume ID False
q_err yes Use QERR bit False
q_type simple Queue TYPE True
queue_depth 2 Queue DEPTH True
reassign_to 120 REASSIGN time out True
rw_timeout 60 READ/WRITE time out True
scsi_id 0x280400 SCSI ID False
start_timeout 60 START UNIT time out True
ww_name 0x50060e8000c28b04 FC World Wide Name False

 

[p5wizard]

All out of ideas, sorry.

HTH,

p5wizard

 

[mrn]

Try certify media / format media option in diag

Mike

"Whenever I dwell for any length of time on my own shortcomings, they gradually begin to seem mild, harmless, rather engaging little things, not at all like the staring defects in other people's characters."

 

[p5wizard]

Have you seen anything in errpt after a failed extendvg attempt?


HTH,

p5wizard

 

[mrn]

may also be worth opeing a call with IBM....

Mike

"Whenever I dwell for any length of time on my own shortcomings, they gradually begin to seem mild, harmless, rather engaging little things, not at all like the staring defects in other people's characters."

 

[HCUR]

Hi,

is there any news on the extendvg problem?
It seems I'm having exactly the same problem with HDS disks.

Thanks
HCUR

 

[ereshatezer]

Hi,

No solution up to now.
The existing VG still can't be extended so a new VG has been created.

 

[samirm]

I am not sure. But I found this information.

Another option you may have to convert your "Standard Volume Group" to a "Big Volume Group". This will allow you to have up to 64 physical volumes in the volume group with the t-factor size set to 2 (128 if the t-factor size set to 1). You would change your volume group to "Big" by running the following:

chvg -B <vgname>

or

smitty chvg
key in your vgname
Change a Volume Group

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

[Entry Fields]
* VOLUME GROUP name samplevg
* Activate volume group AUTOMATICALLY yes +
at system restart?
* A QUORUM of disks required to keep the volume yes +
group on-line ?
Convert this VG to Concurrent Capable? no +
Change to big VG format? yes +
LTG Size in kbytes 128 +
Set hotspare characteristics n +
Set synchronization characteristics of stale n +
partitions



1. The -B flag cannot be used if there are any stale physical partitions or
there are any open logical volumes in the volume group.

2. Once the volume group is converted, it cannot be imported into AIX 4.3.1 or
lower versions.

3. The -B flag cannot be used if the volume group is varied on in concurrent
mode.

4. There must be enough free partitions available on each physical volume for
the VGDA expansion for this operation to be successful.

5. Since the VGDA resides on the edge of the disk and it requires contiguous
space for expansion, the free partitions are required on the edge of the
disk. If those partitions are allocated for user usage, they will be
migrated to other free partitions on the same disk. The rest of the
physical partitions will be renumbered to reflect the loss of the
partitions for VGDA usage. This will change the mappings of the logical to
physical partitions in all the PVs of this VG. If you have saved the
mappings of the LVs for a potential recovery operation, you should generate
the maps again after the completion of the conversion operation. Also, if
the backup of the VG is taken with the map option and you plan to restore
using those maps, the restore operation may fail since the partition number
may no longer exist (due to reduction). It is recommended that backup is
taken before the conversion, and right after the conversion if the map
option is utilized. Since the VGDA space has been increased substantially,
every VGDA update operation (creating an LV, changing an LV, adding a PV,
and so forth) may have a considerably longer duration.

6. A big VG only supports Enhanced Concurrent Capable.

7. Because the VGDA space has been increased substantially, every VGDA update
operation (creating a logical volume, changing a logical volume, adding a
physical volume, and so on) may take considerably longer to run.

 

[mrn]

What type is the SAN?

Mike

"Whenever I dwell for any length of time on my own shortcomings, they gradually begin to seem mild, harmless, rather engaging little things, not at all like the staring defects in other people's characters."

 

[HCUR]

HDS 9570V