pvdisplay -- ERROR "pv_read(): pv_create_name_from_kdev_t" no VALID physica
Hello, i have the following problem with powerpath on linux: on some devices i can not use powerpath device name but only one of the SAN path device file.
Is the volume a Clariion snap of a existing volume seen by the same server?
If it is, I'm not sure how the LVM will react because the snap will have the same UUID as the already imported source volume. That may be why its saying it can't find a valid physical volume.
I don't know how you handle that situation in Linux. On other platforms you have to somehow change the UUID, vgid, or equivalent. It can be quite tricky to import array snaps back onto the same host.
If that's not the case here, forgive my intrusion.
2) yes i'm pressenting snap devices on the same server than the source, but its working for 90% of the devices. And even if i have problems with pseudo name, as you can see, the deferent san path devices for this pseudo are working well. So i think it's only a problem related to powerpath itself and the way it's declaring pseudo devices on the system.
(Item 5 - Is there a way to activate/mount a copy of a volume group taken with a disk-array based point-in-time copy on the same host? The problem I have occurs because the disk-array copy contains all information on the disk, including PVID/VGID's, which is confusing for Linux's LVM.)
found it. I'm aware of the problem about the unique vgid but i'm not sure that it's my problem because i can pvdisplay one of the path to pv under the pseudo device name that is not responding to pvdisplay... the id is supposed to be the same between the pseudo and its different paths.
for example, here is another snap device from the same session that is fully working well:
You're right, the ID is supposed to be the same for the powerpath pseudo (parent) device & all the childen - but in the case of a snap presented back to the same host, you'll have two different devices with the same PVID because the snap is an exact copy including all the LVM metadata.
If you reboot a host with duplicate UUIDs there's a chance that the LVM will pick up the snap device before the source - and import the snap instead. This can lead to data loss in the future as new writes will go to the snap instead of the source.
Anyway, I take your point about pvdisplay working for some and not others. Try the following which might give some clues (maybe post the output if its not too long):
# lvmdiskscan -v # powercf -q (not sure if this exists in Linux PowerPath) # powermt config # powermt display # powermt check # ls -l /dev/emcpowerq* # pvdisplay -vv /dev/emcpowerq1 (that two v's) # pvdisplay -vv | grep xKf1sO-33a7-SX0H-xS1p-7rNp-YpPL-ZJXgCA This should find all the paths with the above ID, as taken from your earlier post. # pvscan -u # dmesg
Check the messages/syslog file for any LVM related errors.
the pvuuid are the same for the source and the snap. And when i check all the pseudo devices pairs (source/snap): when the pseudo work for the source, it doesn't work for the snap, and when it works for the snap it doesn't work for the source. Anyway for a snap it's strange that pvdisplay work for one the path and not for the pseudo (with the same pvuuid).
I've not not found a simple method to change pvuuid. Does someone ever do this on Linux ?
MarcT2
2 Intern
•
131 Posts
1990
0
Posted February 6th, 2008 06:00
If it is, I'm not sure how the LVM will react because the snap will have the same UUID as the already imported source volume. That may be why its saying it can't find a valid physical volume.
I don't know how you handle that situation in Linux. On other platforms you have to somehow change the UUID, vgid, or equivalent. It can be quite tricky to import array snaps back onto the same host.
If that's not the case here, forgive my intrusion.