Cannot extend vg - but why ?
Richard
I get the error: 0516-792 extendvg: Unable to extend volume group.
(no more clues)
This is the lsvg output:
VOLUME GROUP: vgga03 VG IDENTIFIER:
0000000000004c00000000f4fe19aa31
VG STATE: active PP SIZE: 64
megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 10621
(679744 megabytes)
MAX LVs: 256 FREE PPs: 2302
(147328 megabytes)
LVs: 15 USED PPs: 8319
(532416 megabytes)
OPEN LVs: 15 QUORUM: 10
TOTAL PVs: 19 VG DESCRIPTORS: 19
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 19 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
This is the lsattr -El hdisk output:
clr_q no Device CLEARS its Queue
on error True
location Location
Label True
lun_id 0x85000000000000 Logical Unit Number
ID False
max_transfer 0x40000 Maximum TRANSFER
Size True
node_name 0x50060e800042a512 FC Node
Name False
pvid 00c71eaed4de2d9c0000000000000000 Physical volume
identifier False
q_err yes Use QERR
bit True
q_type simple Queuing
TYPE True
queue_depth 1 Queue
DEPTH True
reassign_to 120 REASSIGN time out
value True
rw_timeout 30 READ/WRITE time out
value True
scsi_id 0xd50000 SCSI
ID False
start_timeout 60 START unit time out
value True
ww_name 0x50060e800042a512 FC World Wide
Name False
The lsattr output differs not from disks that are already in the vg, a
chvg -t does not work because there are already 19 disks in the vg
(and that's not the issue). The new hdisk is 35G so the nr of PP's
stay under 1016. I also cleared the pvid of the hdisk but this did not
solve anything, all I got was:
0516-1254 extendvg: Changing the PVID in the ODM.
0516-792 extendvg: Unable to extend volume group.
So there is no lock on it or something like that.
Any advise will be appreciated,
Richard.
Geert
"Richard" <Richard....@gmail.com> schreef in bericht
news:1188989009.0...@k79g2000hse.googlegroups.com...
Richard,
Could be the disk defect?
Geert
Richard
I just tried. I've created another VG with the disk and everythings
works fine. So the disk is allright.
Richard.
uruk-hai
extendvg -f maybe?
Hajo Ehlers
Please read:
EXTENDVG DOES NOT WRITE VGDA TO NEW DISKS
http://www-1.ibm.com/support/docview.wss?uid=isg1IY71108
Check that the VDGA Size did not reach 8744 blocks
http://www-1.ibm.com/support/docview.wss?uid=isg1IY69185
$ readvgda /dev/hdiskx
hth
Hajo
Richard
>
> Check that the VDGA Size did not reach 8744 blockshttp://www-1.ibm.com/support/docview.wss?uid=isg1IY69185
Thanks for your reply Hajo,
I never heard of "readvgda", thanks again.
I cannot use it because the existing disks of the VG are in use. I
also checkput the links and we are at 5.3 ML04 so that the bos.rte.lvm
cannot be the case. The only thing I can do now is request some
downtime.
Richard.
Hajo Ehlers
On AIX 5300-06-03 i can use readvgda on active hdisks and EMC
hdiskpower devices. So do you have a problem to run readvgda ? If yes
its looks like a scsi locking issue. For troubleshooting i would also
run a
$ truss -aef extendvg myvg hdiskx
and check for errors and/or compare it to a working extendvg.
hth
Hajo
Richard
I used the truss command as you suggested and nothing jumped out for
me, but strange was the next output:
auditlog("extendvg", 1, " Volume Group # = 39 Max LV's = 256 VG
descriptor size = 0 PP size = 26", 71) Err#22 EINVAL
PPsize=26?
If I add the disk to another VG everything is allright, so I think
there is something wrong with the existing VG and not the disk. Is it
wise to export/import the VG?
Thanks again,
Richard.
Hajo Ehlers
> PPsize=26?
If the output is from lqueryg ( Run by extendvg ) then it means that
pp size is 2^6 MB which is 64 MB
So that looks correct
>is it wise to export/import the VG?
I would not do it until the cause for the problem is found.
Still my question remains if you can run readvgda ?
Currently i think you have a problem with the VGDA for some reason.
The reason might be:
- the size of the vgda is not correct
Read http://www.redbooks.ibm.com/redbooks/pdfs/sg245432.pdf to
determine the size of the VGDA
- the VGDA of the disks is not equal
Run readvgda -p hdiskXY for each disk and compare each other.
- Through some previous steps of reducevg/extendvg the pv count
within the VGDA is higher then the allowed one. A truss should give
some clue.
hth
Hajo
Richard
readvgda works now , strange but true, here some output
Am I reading right that the vgda size=2098 ??
VG Type = 32 PV VG
lvmid: 1598838349
vgid: 0000000000004c00000000f4fe19aa31
lvmarea_len: 4212
vgda_len: 2098
vgda_psn[0]: 136
vgda_psn[1]: 2242
reloc_psn: 73400063
pv_num: 29
pp_size: 26
vgsa_len: 8
vgsa_psn[0]: 128
vgsa_psn[1]: 2234
version: 30
vg_type: 0
ltg_shift: 4(2048K)
thanks,
Richard.
Hajo Ehlers
> readvgda works now , strange but true, here some output
>
> Am I reading right that the vgda size=2098 ??
vdga_len + 2 * vgsa_len = ( 2*2098 + 2*8 ) = 4212
>
> VG Type = 32 PV VG
...
> pv_num: 29
....
Please run a readvdga -p hdiskX on each disk which belongs to the
trouble making VG.
Search for pv_num on each disk and post the out put
Diff each disk within the VG which the first disk from the VG and post
the output
The reason for this task is to verify that each disk has a valid VGDA
and second that the pv_num is not greate then 32 ( I asume that
extendvg uses this number to detemine if 32 disk are within the
VG ) .
Example:
$ readvgda -p hdisk0 > 0
$ readvgda -p hdisk2 > 2
$ readvgda -p hdiskX > x
diff 0 2
11c11
< pv_num: 1
---
> pv_num: 2
20c20
< *=============== 1ST VGDA-VGSA: /dev/hdisk0 ===============*
---
> *=============== 1ST VGDA-VGSA: /dev/hdisk2 ===============*
...
diff 0 X
Hajo
Henry
can you show the output from this
for pv_name in $( lspv | awk '$4 == "active" {print $1}' ) ; do
print "***************"
print lqueryvg for $pv_name
print "***************"
/usr/sbin/lqueryvg -Atp $pv_name
done
for vg_name in $(lsvg); do
print "***************"
print lqueryvg for $vg_name
print "***************"
/usr/sbin/lqueryvg -Atp $vg_name 2>/dev/null
done
Hans-Joachim Ehlers
still i am interested in the output of the
$ readvgda -p hdiskX
output before you did the exportvg/importvg because to see if the pv_num
is/was the culpid.
Is it still available ?
tia
Hajo