Description of problem: The multipath.conf generated by vdsm on el7 is using an incorrect syntax. Problematic is that any multipath command will fail: # multipath -ll Dec 09 12:03:59 | multipath.conf +5, invalid keyword: getuid_callout Dec 09 12:03:59 | multipath.conf +18, invalid keyword: getuid_callout Dec 09 12:03:59 | multipath.conf +37, invalid keyword: getuid_callout Version-Release number of selected component (if applicable): [root@dell-pet105-02 ~]# rpm -q vdsm ovirt-node device-mapper device-mapper-multipath vdsm-4.16.8.1-2.el7ev.x86_64 ovirt-node-3.1.0-0.32.20141204gitb8c5332.el7.noarch device-mapper-1.02.84-14.el7.x86_64 device-mapper-multipath-0.4.9-66.el7.x86_64 [root@dell-pet105-02 ~]# cat /etc/system-release Red Hat Enterprise Virtualization Hypervisor release 7.0 (20141204.0.el7ev) How reproducible: always Steps to Reproduce: 1. Install RHEV-H 7.0 2. Register RHEV-H 7.0 3. View multipath.conf Actual results: multipath.conf is invalid Expected results: multipath.conf is valid Additional info: [root@dell-pet105-02 ~]# multipath -ll Dec 09 12:03:59 | multipath.conf +5, invalid keyword: getuid_callout Dec 09 12:03:59 | multipath.conf +18, invalid keyword: getuid_callout Dec 09 12:03:59 | multipath.conf +37, invalid keyword: getuid_callout [root@dell-pet105-02 ~]# cat /etc/multipath.conf # RHEV REVISION 1.1 defaults { polling_interval 5 getuid_callout "/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/%n" no_path_retry fail user_friendly_names no flush_on_last_del yes fast_io_fail_tmo 5 dev_loss_tmo 30 max_fds 4096 } devices { device { vendor "HITACHI" product "DF.*" getuid_callout "/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/%n" } device { vendor "COMPELNT" product "Compellent Vol" no_path_retry fail } device { # multipath.conf.default vendor "DGC" product ".*" product_blacklist "LUNZ" path_grouping_policy "group_by_prio" path_checker "emc_clariion" hardware_handler "1 emc" prio "emc" failback immediate rr_weight "uniform" # vdsm required configuration getuid_callout "/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/%n" features "0" no_path_retry fail } }[root@dell-pet105-02 ~]#
Workaround: Manually uncommenting the getuid_callout directive solves the problem.
Lowering the priority, because the incorrect multipath.conf does not keep the multipath command from returning good informations.
This warning usually means that scsi_id isn't where multipath thinks it is. Vanila RHEL 7.0 indeed has /usr/lib/udev/scsi_id, provided by the systemd-208-11.el7.x86_64 rpm. Fabian, is this different for RHEVH?
The systemd version seems to be correct, also the path seems to be correct: [root@dell-pet105-02 ~]# rpm -q systemd systemd-208-11.el7_0.4.x86_64 [root@dell-pet105-02 ~]# rpm -ql systemd | grep scsi_id /usr/lib/udev/scsi_id To me the error: Dec 09 12:03:59 | multipath.conf +5, invalid keyword: getuid_callout rather looks like getuid_callout is unknown.
I just learned: """In RHEL7, multipath no longer uses "getuid_callout" to grab the wwid. It gets the wwid from the udev database or the udev environment variables (if the value is not in the database yet). By default is uses ID_SERIAL. You can change that with the "uid_attribute" option. Having "getuid_callout" in your config file will trigger a warning, but doesn't harm anything.""" Source: bug 1152948 comment 89
Ah huh! Now I remember where I encountered this - see bug 1140748. For RHEV 3.6, once we drop support for EL6, we should fix this properly. Before that, I don't think it's worth the risk/effort.
This is only a warning and does not effect the operation of multipath. Same issue exists on Fedora.
Merge upstream: https://github.com/oVirt/vdsm/commit/18d17944cade58a9eaa74e16b76c80d3246d221a
Nir, is there anything else we need besides the merged https://gerrit.ovirt.org/#/c/41241/ ? If so - please specify what.
No, this is ready for qa.
Verified on 3.6 RHEV-M hypervisor
*** Bug 1298454 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0362.html