/dev/dm-NN devices and multipaths getting created even if multipathd service is OFF!

[Alzhy]

Aside from de-installing the device multipath bits -- is there anyway the /dev/dm devices can be stopped from being generated at boot time?

I have the multipathd service OFF and yet after a server reboots - /dev/dm-NN devices are present and multipath -ll shows multipath devices. "service multipathd status" shows multipathd service is off/stopped

[Tim Nelson]

just a guess but...

device-mapper-multipath package includes /etc/udev/rules.d/40-multipath.rules

??

[Alzhy]

So those are boot time directives independent of multipathd settings?

[Tim Nelson]

I do not know that for sure.

is multipath still in your kernel ? lsmod|grep multi

maybe try to pull it out and also rebuild the initrd

or wait for Matti to chime in.. he knows everything ;)

[Alzhy]

Yeah... been wanting to go that route, remove from initrd modules OR just uninstall the device mapper / multipath bits.


Environment is RHEL under vMware. We just started using RDMs in physical compatibility mode. So the OS "sees" the already multipathed LUNS (from ESX) and tries to mutipath them too..

I have renamed 40-multipath.rules to _40-multipath.rules and the /dev/dm-NN devices are gone. However, "multipath -ll" still shows multipath definitions.

[Tim Nelson]

what if you deneied them all in the multipath.conf ?

[Alzhy]

Opting to remove instead device mapper and multipath bits from the OS.

Tis is a vLinux RHEL server anyway and vSphere manages the multipathing to the SAN LUNs

[Matti_Kurkela · Accepted solution]

When you install device-mapper-multipath in RHEL 4 and 5, the default multipath.conf file includes an entry that denied everything.

You must remove that entry to enable multipathing - so analogously, adding that denied entry back would disable multipathing.

Device-mapper-multipathing has four main components:
- the userspace "multipath" command
- the userspace "multipathd" daemon
- the kernel module dm_multipath
- the udev rules file for dm-multipath

The multipathd daemon monitors multipath devices for failed paths, switches path groups as necessary, and re-enables failed paths once they become available again - nothing more.

The kernel module and the udev rules do the most of the work when multipathed disks are detected.

So disabling the multipathd daemon/service disables only part of the dm-multipath system... and that isn't the part responsible for detecting new devices.

Because all the userspace components of the dm-multipath system use the /etc/multipath.conf file, denied everything in the configuration file is the correct way to disable dm-multipath.

MK

[MSwift]

Greetings!

And the reboot is a must after the changes to multipath.conf? or is there a way to re-read the multipath.conf after denied or uncommenting the blacklist.

Thanks

Mike.

[Matti_Kurkela]

No reboot required.

If all your multipathed disks are unmounted (and any databases and other applications that might use raw disks are shut down), you can use "multipath -F" to remove all unused multipath devices (= all of them, if you didn't forget to unmount/shutdown anything).

After that, you can run "multipath -v2": when invoked without the "-l" option, the multipath command will read multipath.conf, and then will re-scan all currently visible disk devices on the system. If all devices are denied in multipath.conf, it should leave all the disks alone. The "-v2" option just gives you immediate visual feedback in case the multipath command still finds an eligible multipathed disk.

MK