Red Hat Bugzilla – Bug 596323
"multipath -c" needs /etc/multipath/wwids
Last modified: 2010-11-10 15:10:37 EST
"multipath -c" in /lib/udev/rules.d/40-multipath.rules need wwids, although /etc/multipath.conf is present with a wwid. anaconda seems to ship an empty file after installation.
In theory "multipath -c" should only need /etc/multipath.conf.
That's only true if you don't use "find_multipaths". If you do, then the only way you can tell if the first path in a multipath device is a valid multipath device, is by checking the wwids file. Perhaps this bug should be opened against anaconda.
Did a bug get opened against anaconda for this? If not, do you have any objection to me changing the component to anaconda?
(In reply to comment #3)
> Did a bug get opened against anaconda for this? If not, do you have any
> objection to me changing the component to anaconda?
bug against anaconda is bug 596320
Then does this bug still need to be opened? What would you like device-mapper-multipath to do differently?
the udev rule with "multipath -c" could use the ID that udev already finds out with scsi_id and could look in /etc/multipath.conf
Does the udev scsi_id only work for SCSI devices, because multipath isn't limited to simply scsi devices. Right now multipath allows storage vendors to set the wwid callout on a per-device-type basis. This is necessary, because there is no one callout that correctly gives a unique ID for every device multipath supports. In the future, I hope we will be able to use a udev given ID, but change would have to go into fedora first, and we'd have to make certain that it worked for the range of multipath devices. I'd don't know how the udev scsi_id is generated, but if it simply calls scsi_id with the same parameters, it won't work for all the multipath devices we support.
And I don't see how looking in /etc/multipath.conf will help this. If I understand the problem correctly, it's that after initial installation, the multipathed devices are not in /etc/multipath/wwids, and so multipath -c doesn't return that the device is multipathed. If you have a multipathed root or boot device, this will probably remain so, since multipath add the devices to /etc/multipath/wwids on creation, and you can't write to that file when you are creating the multipath devices in the initrd.
The simplist solution is to add these devices to /etc/multipath/wwids when you are building an initramfs that creates multipath devices. For all multipath devices that aren't started up in initramfs, as soon as multipath creates them for the first time after installation, they will get entered into /etc/multipath/wwids.
I suppose multipath could have a command that it ran on boot that looked at the
current multipath devices, and made sure that they were in /etc/multipath/wwids. But if you want multipath -c to work with the find_multipaths option, you need to use /etc/multipath/wwids. Otherwise, when the first device appears, multipath won't have any way of knowing whether or not the device should be multipathed, unless you want this to rely on the configuration file being set up a certain way.
I've made the multipath command automatically add the wwids from existing multipath devices to /etc/multipath/wwids, if they are not there. Since this is run in /etc/rc.sysinit. Multipath should now automatically add the wwids from all the existing multipath devices that are created in early boot. This should solve your problem, unless anaconda is setting up multipathing devices, and but not creating the devices in the initrd. If that is the case, "multipath -c" will not recognize these devices as multipath devices until after the first time that multipath creates them. There's no easy way around this problem, except by having anaconda do the create that file.
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.