Hi Ilan, I believe this is solved by the following patch: http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=commit;h=5adec73edcdee912821ca8378439dc105e82c60f Per the patch description: When a system is booted to the SAN, a condition can occur where one user friendly name is given to a disk during boot, but multipathd tries to allocate a different one after boot. If the second alias is already used by another device, multipathd can't rename it. Multipathd then has incorrect information about the alias/wwid relationships, which can result in paths being added to the wrong map. On Thu, 2015-03-19 at 10:35 +0000, Ilan Steinberg wrote: > multipathd> show maps > name sysfs uuid > mpathiw dm-13 20024f400d5190010 This shows the current running configuration, that multipathd is operating believing that mpathiw should have be 20024f400d5190010. > This might be useful info - in the bindings file I see: > > ... > > mpathiv 20024f400d5190010 > <---------------------------------------- this is the scsi_sn of sdag > > mpathiw 20024f400d5190026 > <---------------------------------------- this is the scsi_sn of sdz/w > > ... > So what must have happened was that the bindings file was out of sync on the initramfs and the local fs (which you can check by unwrapping the initramfs and comparing the wwids in each file), and it created the device with one name, tried to rename it, couldn't, and multipathd then starts adding into the wrong map. It's hard to explain clearly. :) If we could see what both bindings files say, maybe I could explain it better. To work around it, remaking the initramfs to sync the bindings should suffice, or you could define aliases via the multipath sections multipath.conf. Hope this helps. Thanks, Sean Stewart -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
