LVM and disk question.

[Chris Fadrowski]

I get the following when doing a vgdisplay on a volume group

root@yeti:/>vgdisplay vgy11
vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c9t0d1":
The specified path does not correspond to physical volume attached to
this volume group
vgdisplay: Warning: couldn't query all of the physical volumes.
--- Volume groups ---
VG Name /dev/vgy11
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 1
Open LV 1
Max PV 16
Cur PV 1
Act PV 1
Max PE per PV 25599
VGDA 2
PE Size (Mbytes) 4
Total PE 25596
Alloc PE 25000
Free PE 596
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0


notice the warning. The server is accessing its disk just fine and the DB's are running. However this warning concerns me. I did switch out a fiber channel port last night which i imagine is causing this issue.

Would it be wise to rename /etc/lvmconf to lvmconf.old and run a new vgscan? doesn't the make the system unavailable if i execute this?

[Tim Nelson]

"/dev/dsk/c9t0d1" is dead/broke or does not exist.

1) please post a full vgdisplay -v /dev/vgy11

2) If this is truly just a bogus disk that you do not want or need a vgreduce -f may fix before going to the vgscan road.

[Chris Fadrowski]

full output

root@host:/>vgdisplay -v /dev/vgy11
vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c9t0d1":
The specified path does not correspond to physical volume attached to
this volume group
vgdisplay: Warning: couldn't query all of the physical volumes.
--- Volume groups ---
VG Name /dev/vgy11
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 1
Open LV 1
Max PV 16
Cur PV 1
Act PV 1
Max PE per PV 25599
VGDA 2
PE Size (Mbytes) 4
Total PE 25596
Alloc PE 25000
Free PE 596
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c9t0d1":
The specified path does not correspond to physical volume attached to
this volume group
vgdisplay: Warning: couldn't query all of the physical volumes.
--- Logical volumes ---
LV Name /dev/vgy11/lvol111
LV Status available/syncd
LV Size (Mbytes) 100000
Current LE 25000
Allocated PE 25000
Used PV 1


--- Physical volumes ---
PV Name /dev/dsk/c11t0d1
vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c9t0d1":
The specified path does not correspond to physical volume attached to
this volume group
vgdisplay: Warning: couldn't query all of the physical volumes.
PV Status available
Total PE 25596
Free PE 596
Autoswitch On
Proactive Polling On

[Chris Fadrowski]

also ioscan -fnC disk doesn't work now. it just hangs.

[Tim Nelson]

Initial thought is that the c9t0d1 is toast, with your ioscan comment I would say it probably is hanging the bus.

If you can figure out what physical device it is, and if it is hot-swappable then pull it out...

What type of disk config, direct attached SCSI ? One of the drives may have have its light on solid. That would be my guess.

I would guess a pile of lbolt errors are in syslog.log as well.

[Chris Fadrowski]

this is attached to a Hitachi SAN. After moving some cables to a 4gb port last night i am getting this today. I looks from the ioscan -funC disk command that it may have changed hw paths

disk 44 0/0/4/1/0.182.0.0.0.10.0 sdisk CLAIMED DEVICE HITACHI DISK-SUBSYSTEM
/dev/dsk/c10t10d0 /dev/rdsk/c10t10d0
disk 45 0/0/4/1/0.182.0.0.0.11.0 sdisk CLAIMED DEVICE HITACHI DISK-SUBSYSTEM
/dev/dsk/c10t11d0 /dev/rdsk/c10t11d0
disk 46 0/0/4/1/0.182.0.0.0.12.0 sdisk CLAIMED DEVICE HITACHI DISK-SUBSYSTEM
/dev/dsk/c10t12d0 /dev/rdsk/c10t12d0
disk 47 0/0/4/1/0.182.0.0.0.13.0 sdisk CLAIMED DEVICE HITACHI DISK-SUBSYSTEM
/dev/dsk/c10t13d0 /dev/rdsk/c10t13d0
disk 48 0/0/4/1/0.182.0.0.0.14.0 sdisk CLAIMED DEVICE HITACHI DISK-SUBSYSTEM
/dev/dsk/c10t14d0 /dev/rdsk/c10t14d0
disk 49 0/0/4/1/0.182.0.0.0.15.0 sdisk CLAIMED DEVICE HITACHI DISK-SUBSYSTEM
/dev/dsk/c10t15d0 /dev/rdsk/c10t15d0
disk 75 0/0/6/1/0.110.0.1.0.0.0 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c14t0d0 /dev/rdsk/c14t0d0
disk 76 0/0/6/1/0.110.0.1.0.0.1 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c14t0d1 /dev/rdsk/c14t0d1
disk 77 0/0/6/1/0.110.0.1.0.0.2 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c14t0d2 /dev/rdsk/c14t0d2
disk 78 0/0/6/1/0.110.0.1.0.0.3 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c14t0d3 /dev/rdsk/c14t0d3
disk 79 0/0/6/1/0.110.0.1.0.0.4 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c14t0d4 /dev/rdsk/c14t0d4
disk 80 0/0/6/1/0.110.0.1.0.0.5 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c14t0d5 /dev/rdsk/c14t0d5
disk 81 0/0/6/1/0.110.0.1.0.0.6 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c14t0d6 /dev/rdsk/c14t0d6
disk 82 0/0/6/1/0.110.0.1.0.0.7 sdisk CLAIMED DEVICE HITACHI OPEN-V
/dev/dsk/c14t0d7 /dev/rdsk/c14t0d7
disk 83 0/0/6/1/0.110.0.1.0.1.0 sdisk CLAIMED DEVICE HITACHI OPEN-V


from c9 to c14. could i vgreduce -f and then extend the vg to c14txdx?

[Steve Reynolds]

Would you have a map file of the
volume group from an vgexport?

It may be possible to rebuild the
volume group with a vgimport.
Either specifying the new disk path
or with the -s using the disk identifer.

[Vihang.]

Hi Chris,

Perform the below steps to get the VG to use the new device files.

# Stop applications using the filesystems.
# Unmount filesystems belonging to the VG.
# Deactivate the VG (vgchange -a n vgy11)
# Note the group device file details (ls -l /dev/vgy11)
# Create a temp map file for safety (vgexport -s -p -m /tmp/vgy11.map vgy11)
# Export the VG (vgexport vgy11)
# Create the directory (mkdir /dev/vgy11)
# Create group device file (mknod /dev/vgy11/group c 64 0xx0000 where xx is the minor no as noted in previous command)
# Import the VG with new device files (vgimport /dev/vgy11
# Activate the VG (vgchange -a y vgy11)
# Check the VG (vgdisplay -v vgy11)
# Mount as before.

Regards,
Vihang.

[Deepak Kr]

Chris,

One more thing here:

was this disk "/dev/dsk/c9t0d1" was in mirror under this VG vgy11?

If yes then you have to lvreduce first on this vg using -k option
e.g

lvreduce -k -m mirror_copies lv_path
then
vgreduce...

best way is to use previously exported map file as disk eventhough has different name but still contains same vg info in header.