[dm-devel] oblem with lvm and multipath on fedora 13
Stamper, Brian P. (ARC-D)[Logyx LLC]
brian.p.stamper at nasa.gov
Sun Aug 29 19:08:18 UTC 2010
>So run "kpartx -a /dev/mapper/<yourmultipathdevice>" on each multipath
>device and then run LVM scan.
>If LVM still uses paths and complains about duplicate PVs, then you may
>need create a right filter in /etc/lvm/lvm.conf to use intended devices.
>I hope this is not necessary.
This works and is a huge improvement. At least I can get my devices back into multipath manually. Thanks so much for this. I still need to get to the bottom of why these specific volumes are getting grabbed before multipath can get them, but this is a big step.
>Did you enable multipathd service (I thought it should call kpartx or maybe a udev rule)?
Yes, it's chkconfig'ed on, and I bumped forward its start order to start up prior to lvm2-monitor, thinking lvm2-monitor (which does vgscan) might be part of the problem.
>> [root at testfs foo]# find . -print | grep -i multi
>> ./lib/modules/2.6.33.8-149.fc13.x86_64/kernel/drivers/md/dm-multipath.ko
>The dm-multipath.ko kernel module is present. It needs multipath command
>calling from an initrd script (/init ???)
I'm not positive that I'm sure what you're asking. Do you mean the init.d script I reference above, or is there some other configuration change to call mulitpath from initrd?
I feel much better knowing that I can get back to a proper configuration manually, but any ideas about why this is happening on bootup? FYI, I played around with filtering in lvm.conf in my first night of troubleshooting and tried filtering out all /dev/sd.* drives other than /dev/sda, but it seems like dracut was ignoring the lvm filters, despite the lvm.conf. With the filter in place a pvscan would find no duplicates (and no sd.* devices) but on reboot dracut would find them all and report the dupes.
Thanks for your help so far Malahal.
-Brian
More information about the dm-devel
mailing list