Description of problem: When running s-c-lvm, it throws a traceback (attached) upon scan and fails to start. Version-Release number of selected component (if applicable): RHEL 4.5 AS x86_64 device-mapper-multipath 0.4.5-27.el4_6.3 system-config-lvm 1.0.23-1.0. How reproducible: Unknown. Steps to Reproduce: 1. Install RHEL 4.5 AS x86_64 2. Install device-mapper-multipath and system-config-lvm 3. Configure LVM to make use of /dev/mpath entries as PVs. 4. up2date -uf to RHEL 4.6 AS x86_64 5. Run s-c-lvm Actual results: Expected results: Additional info:
Created attachment 297849 [details] Traceback thrown when s-c-lvm is started. Traceback thrown when s-c-lvm is started.
Created attachment 297850 [details] A verbose lvs Per jparsons, I was asked to run a scan with a more verbose lvs output so that he could see what was going on. This is the output of the command: lvs --nosuffix --noheadings --units b --separator \; -o lv_name,vg_name,stripes,stripesize,lv_attr,lv_uuid,devices,origin,snap_percent,seg_start,seg_size,vg_extent_size,lv_size,mirror_log --all
Created attachment 297851 [details] fdisk -l and pvscan Again, per jparsons I have recorded a copy of fdisk -l and pvscan so that the disk configuration can be ascertained.
Created attachment 299337 [details] s-c-lvm output using modified lvm_model.py on a system that is working.
Created attachment 299369 [details] Output from multipath -ll on working machine.
Created attachment 299371 [details] Output from multipath -ll on non-working machine.
Can you attach an lvmdump from the two systems so I can try to reproduce with the same metadata you're using? Just run the command "lvmdump" and attach the tarball it drops into /root.
I have worked very dilligently to reproduce this problem. I procurred dual-I/O qlogic fiber cards and installed them in a test cluster we have available in Westford. Then, I set up multiple fiber paths to storage and ran s-c-lvm on the node. I cannot get this to fail. That said, however, a traceback should never occur and I have modified the code so that if the error described here does happen, an exception is caught and an explanatory dialogue window is displayed. Ready to build this stopgap solution today.
What is in /etc/lvm/lvm.conf? In particular, the filter line should filter out the /dev/sd* devices and you should be setting preferred_path to /dev/mapper/mpath*, not /dev/mpath/... devices. Something like this (assumes all /dev/sd* devices are underlying paths of dm-mp): # Show multipath names if there are any preferred_names = [ "/dev/mapper" ] # Filter out underlying /dev/sd* devices (these are underlying dm-mp paths) filter = [ "r|/dev/sd.*|", "a/.*/" ] I saw the below step #3 in the description and it made me wonder if a misconfiguration exposed this problem. Steps to Reproduce: 1. Install RHEL 4.5 AS x86_64 2. Install device-mapper-multipath and system-config-lvm ===>3. Configure LVM to make use of /dev/mpath entries as PVs.
testing and completing it now. will build today
Yes - This problem was originally evident in a cluster. I set up a similar MP configuration on one of our test clusters many weeks ago, and could not reproduce. I have tinkered on this during the entire 4.7 dev cycle with no luck, BUT: Tracebacks should not happen, so I thought it was at least worthwhile adding and exception handler for this condition, instead of just marking the bug CANT_REPRODUCE. Using this application on a cluster with multiple paths to shared storage is a common occurence. No other user has reported this condition, so I feel confident this must be a peculiarity in the way the reporters cluster storage is set up. All I can do is remain vigilent for a similar report in the future and trap this condition so that the application doesn't quit.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0654.html