Issue with duplicate PVs and failed / faulty dm devices
Linux - EnterpriseThis forum is for all items relating to using Linux in the Enterprise.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Issue with duplicate PVs and failed / faulty dm devices
We are in the process of migrating from a Hitachi SAN to a EMC VNX SAN. I split the HBAs and set up mirroring. After about 1 month of stability, I have stopped the mirroring and am now cleaning up the old Hitachi device files.
We are currently running Red Hat Enterprise Linux AS release 4 (Nahant Update 9)
Here is a lvs listing:
[root@rpsior06 mapper]# lvs /dev/sda: read failed after 0 of 4096 at 0: Input/output error /dev/sdq: read failed after 0 of 4096 at 0: Input/output error
/dev/sdag: read failed after 0 of 4096 at 0: Input/output error
/dev/dm-14: read failed after 0 of 4096 at 0: Input/output error
/dev/dm-15: read failed after 0 of 4096 at 0: Input/output error
/dev/sdb: read failed after 0 of 4096 at 0: Input/output error
/dev/dm-16: read failed after 0 of 4096 at 0: Input/output error
/dev/dm-17: read failed after 0 of 4096 at 0: Input/output error
/dev/dm-18: read failed after 0 of 4096 at 0: Input/output error
/dev/dm-19: read failed after 0 of 4096 at 0: Input/output error
/dev/dm-20: read failed after 0 of 4096 at 0: Input/output error
/dev/dm-21: read failed after 0 of 4096 at 0: Input/output error
/dev/dm-22: read failed after 0 of 4096 at 0: Input/output error
/dev/dm-23: read failed after 0 of 4096 at 0: Input/output error
/dev/dm-24: read failed after 0 of 4096 at 0: Input/output error
Found duplicate PV vqZhTX2fyxODUXgb50PvIn26SZUKx3Wp: using /dev/dm-26 not /dev/dm-10
/dev/sdc: read failed after 0 of 4096 at 0: Input/output error
/dev/sds: read failed after 0 of 4096 at 0: Input/output error
/dev/sdd: read failed after 0 of 4096 at 0: Input/output error
/dev/sde: read failed after 0 of 4096 at 0: Input/output error
/dev/sdu: read failed after 0 of 4096 at 0: Input/output error
/dev/sdf: read failed after 0 of 4096 at 0: Input/output error
/dev/sdg: read failed after 0 of 4096 at 0: Input/output error
/dev/sdw: read failed after 0 of 4096 at 0: Input/output error
/dev/sdh: read failed after 0 of 4096 at 0: Input/output error
/dev/sdx: read failed after 0 of 4096 at 0: Input/output error
/dev/sdi: read failed after 0 of 4096 at 0: Input/output error
/dev/sdy: read failed after 0 of 4096 at 0: Input/output error
/dev/sdj: read failed after 0 of 4096 at 0: Input/output error
/dev/sdk: read failed after 0 of 4096 at 0: Input/output error
/dev/sdaa: read failed after 0 of 4096 at 0: Input/output error
/dev/sdac: read failed after 0 of 4096 at 0: Input/output error
/dev/sdo: read failed after 0 of 4096 at 0: Input/output error
/dev/sdae: read failed after 0 of 4096 at 0: Input/output error
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
LogVol00 VolGroup00 -wi-ao 10.00G
LogVol01 VolGroup00 -wi-ao 16.00G
LogVol02 VolGroup00 -wi-ao 50.00G
LogVol03 VolGroup00 -wi-ao 10.00G
LogVol04 VolGroup00 -wi-ao 10.00G
LogVol05 VolGroup00 -wi-ao 10.00G
LogVol00 VolGroup01 -wi-ao 100.00G
LogVol00 VolGroup02 -wi-ao 650.00G
LogVol00 VolGroup03 -wi-ao 650.00G
LogVol00 VolGroup04 -wi-ao 650.00G
LogVol00 VolGroup05 -wi-ao 50.00G
LogVol00 VolGroup06 -wi-ao 650.00G
LogVol00 VolGroup07 -wi-ao 100.00G
LogVol00 VolGroup08 -wi-ao 100.00G
LogVol00 VolGroup09 -wi-ao 65.00G
LogVol00 VolGroup10 -wi-ao 65.00G
LogVol00 VolGroup11 -wi-ao 65.00G
LogVol00 VolGroup12 -wi-ao 100.00G
[root@rpsior06 mapper]#
Here is a multipath listing:
[root@rpsior06 mapper]# multipath -v2
remove: mpath27 (dup of mpath18)
mpath27: map in use
remove: mpath28 (dup of mpath17)
mpath28: map in use
remove: mpath29 (dup of mpath27)
mpath29: map in use
remove: mpath30 (dup of mpath14)
mpath30: map in use
remove: mpath32 (dup of mpath37)
mpath32: map in use
remove: mpath33 (dup of mpath35)
mpath33: map in use
remove: mpath23 (dup of mpath31)
mpath23: map in use
remove: mpath24 (dup of mpath15)
mpath24: map in use
remove: mpath25 (dup of mpath28)
mpath25: map in use
[root@rpsior06 mapper]#
I'm trying to fix the failed and faulty problems and the duplicate PVs and cannot find out how to fix them. Any and all help would be greatly appreciated! If you need any further information please feel free to ask. Sincerely, Lee
Last edited by lhiggie1; 06-19-2012 at 09:29 PM.
Reason: Formatted the text as it was all run together.
Are you using LVM2 with SAN LUNs? If so, it requires special care (and is extremely dangerous to your data, if that care is not followed). LVM2 is not cluster-aware.
RHEL4's official life cycle has ended. That has little or nothing to do with your question, but keep it in mind if you aren't already.
Please use code tags when posting command output.
If the answer to the first question is "yes", a good rule of thumb to follow is "any time you make PV, VG, or LV changes, reboot all systems that access the affected LUN(s)". I know that sounds excessive. But - at least in my case - data integrity is the most important consideration.
1. We are using LVM2 with SAN LUNs. However, we are not in a clustered environment. I'm in the process of migrating the data from one SAN (Hitachi) to a new SAN (EMC VNX). I'm using LVM mirroring and when I stopped the mirror and disconnected the fibre from the Hitachi and connected the fibre to the EMC is when I received these errors.
2. Yes, I'm fully aware of the lifecycle of RHEL4. I had no choice in the matter due to the outdated version of Oracle eBS we are running.
3. I apologize for not using code tags. I've never used them, so a learning curve has just been eclipsed. I'll look into it.
I understand about the rule of thumb, however, with production business systems that isn't always a possibility. Fortunately, this is not a production server, however, I still have to schedule reboots due to development work being done on the systems.
To continue about my question, after the split of the fibre, I lost one of my vgs and had to return to the split fibre between the two SANs. Now, I'm trying to clean it up and like you stated earlier, before I go any further, a reboot is in order. I will post back the results after I can get the reboot scheduled.
Again, thank you for your reply and the references!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.