physical volume not attached

[Hunan_1]

Hi all, I got a message when I try to create through sam a new logical volume mirrored.

The message says: The specified path does not correspond to physical volume attached to this volume group.

Could this be a reason for some problems we have on our database in these moments?

Any help would be really appreciated.

[Mark Grant]

Unlikely.

It looks to me that you are trying to mirror your logical volume onto a disk that is not in the same volume group. You can only mirror logical volumes within the same volume group.

[Stuart Abramson_2]

I agree with Mark above. Maybe you need to add the PV to the VG in a previous step.

However, do us a favor: When you do an ioscan:

ioscan -fnkCdisk

do you get any "NO_HW" entries? If you do than you have had some disks "disappear", and that could be bad.

Look in /var/adm/syslog/syslog.log for any disk-looking error messages.

[Hunan_1]

Even when I create the logical volume without the mirror option, I get the same message.

[Hunan_1]

Even when I create the logical volume without the mirror option, I get the same message.

[Hunan_1]

The physical volume belongs to the volume group, when I do a vgdisplay -v vgn_est
I got this message:

vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c9t6d0":
The specified path does not correspond to physical volume attached to
this volume group

[Mark Grant]

Looks like Stuart is more on to something here!

It seems you have a problem with the disk. If it looks OK after the ioscan that Stuart mentions you could try restring the LVM data to the disk with
vgcfgrestore -n vgn_est /dev/rdsk/c9t6d0

[Hunan_1]

The response to ioscan -funC disk, shows some disks as NO_HW but they are not what I'm concerned about.

The specified disk I'm talking about is as CLAIMED.

In the syslog.log file are some reports but are about the others disk shown as NO_HW

[Stuart Abramson_2]

If you get that message:

# vgdisplay -v vgn_est

vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c9t6d0":
The specified path does not correspond to physical volume attached to
this volume group

Then, very simply, the disk once existed, you added it to the VG, and now it's gone. You lost the disk, somehow, and you have to figure out how.

What kind of disks are they? Have you changed anything lately? Moved i/o cables?

Are they EMC disks? Do you have the inq utility?

[Steven E. Protter]

Might want to run the script I'm attaching to see if all your volumes in /etc/lvmtab are actually responsive.

Modify the script to send the email to YOUR email address.

I've already gotten two emails from people with disk layouts. Kinda fun, but I don't need it.

:-)

See attachment.

SEP

[Hunan_1]

That disk always has belonged to that volume group.
No, I haven't changed anything lately, I guess the disks are SCSI2... how can I know that?
If the i/o cables had moved, I guess all the disk that belong the array would be as NO_HW...
Could be a possibility the disk's path is confused to the OS?
I mean It's been moved. Could I set it online (the disks are hot pluggable)?
Before I didn't have any problem like this.
What are EMC disks?
No I don't have the inq utility, what does the inq utility do?

[Sridhar Bhaskarla]

Hi Hunan,

Do a

vgdisplay -v > /tmp/vg.out 2>&1

vi /tmp/vg.out

This should list the disk that the system is complaining about. If you search with that disk device name in the same file, you will find the corresponding volume group.

This message tells that the VG headers on that disk do not match with VG that it belongs to. Either someone did a "pvcreate -f" on it by mistake or you lost that disk.

Try running ioscan,diskinfo,lssf etc., commands to make sure the disk is physically there. If you confirm that it is there and it is in fact the same disk, then do a vgcfgrestore on it to put back the VG headers.

vgcfgrestore -n vgname /dev/rdsk/cxtydz
vgchange -a y vgname

This should fix your issue if the data on that disk is not already overwritten.

-Sri