Bug 1124450 - Wrong default multipath configuration for EL6
Summary: Wrong default multipath configuration for EL6
Alias: None
Product: oVirt
Classification: Retired
Component: vdsm
Version: 3.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.5.1
Assignee: Nir Soffer
QA Contact: Gil Klein
Whiteboard: storage
Depends On:
Blocks: 1108711
TreeView+ depends on / blocked
Reported: 2014-07-29 14:08 UTC by Patrick Hurrelmann
Modified: 2016-02-10 18:03 UTC (History)
12 users (show)

Fixed In Version: ovirt-3.5.1_rc1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-01-21 16:05:27 UTC
oVirt Team: Storage
redhat: needinfo-

Attachments (Terms of Use)
Proposed patch (496 bytes, patch)
2014-07-29 14:08 UTC, Patrick Hurrelmann
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
oVirt gerrit 34839 0 master MERGED multipath: Fix booting from multipath device Never
oVirt gerrit 34840 0 master ABANDONED multipath: Bump multipath configuration version Never
oVirt gerrit 35727 0 ovirt-3.5 MERGED multipath: Fix booting from multipath device Never

Description Patrick Hurrelmann 2014-07-29 14:08:09 UTC
Created attachment 922160 [details]
Proposed patch

Description of problem:

Systems configured to boot from SAN via iSCSI fail to boot after vdsm changed the multipath.conf originally created by anaconda. An updated kernel finally embeds the faulty multipath.conf into the initrd and the boot fails. Multipath is not able to enumerate the multipath disks.

Version-Release number of selected component (if applicable):

Linux test-host.eample.com 2.6.32-431.20.5.el6.x86_64 #1 SMP Fri Jul 25 08:34:44 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Installed Packages
vdsm.x86_64    4.14.9-0.el6

How reproducible:

Steps to Reproduce:
1. Install system with root on SAN (iSCSI multipath)
2. Install vdsm (vdsm overwrites multipath.conf created by anaconda)
3. Update kernel (faulty multipath.conf is embedded into initrd)

Actual results:
Boot fails, multipath cannot enumerate the disks

Expected results:
Boot succeeds, multipath disks can be enumerated

Additional info:

It all boils down to the default value set for option getuid_callout
in multipath.conf. Vdsm sets it to the following:

getuid_callout  "/sbin/scsi_id --whitelisted --replace-whitespace

According to the man-page and other docu the default value on EL6 is
"/lib/udev/scsi_id --whitelisted --device=/dev/%n". Although the binary
/sbin/scsi_id is a valid link to the target /lib/udev/scsi_id, the link
itself (/sbin/scsi_id) is _not_ included in the generated initrd. The
binary /lib/udev/scsi_id is indeed included and changing the default
config to use /lib/udev/scsi_id instead does make it all work again.
iscsi boot (after regenerating the initrd, as the multipath.conf is
embedded) is back to good and the previously logged device-mapper errors
are gone, too.

Comment 1 Allon Mureinik 2014-08-19 14:16:46 UTC
Patrick - thanks for the patch!

Nir, Patrick - who's submitting this to gerrit?

Comment 2 Nir Soffer 2014-08-19 15:16:50 UTC
I will post Patrick patch to gerrit,

Comment 3 Nir Soffer 2014-11-02 20:32:39 UTC
We need more than this patch - we need to upgrade existing multipath conf file created by vdsm versions without this fix.

So the final fix will have to be:
1. Fix the path to scsi_id
2. Bump multipath configuration version, so multipath.conf will be
   upgraded with the correct path when upgrading vdsm.

Comment 4 Nir Soffer 2014-11-03 11:58:00 UTC
Related to bug 1108711

Comment 5 Nir Soffer 2014-11-05 17:08:58 UTC
Patrick, please check your patch in gerrit:

Comment 6 Patrick Hurrelmann 2014-11-24 12:27:01 UTC
Sorry for the delay. The patch looks fine and it is already merged.
Thanks Nir for committing

Comment 7 Nir Soffer 2014-12-21 22:58:20 UTC
Allon, any reason that this should not go into 3.5.1?

Comment 8 Allon Mureinik 2014-12-22 08:01:02 UTC
It's already been delayed THREE times (https://www.ovirt.org/OVirt_3.5.z_Release_Management) - at this point we want to decrease uncertainty, not increase it.

Is there a super-pressing need for this fix in 3.5.1?

Comment 9 Nir Soffer 2014-12-22 13:14:11 UTC
(In reply to Allon Mureinik from comment #8)
> It's already been delayed THREE times
> (https://www.ovirt.org/OVirt_3.5.z_Release_Management) - at this point we
> want to decrease uncertainty, not increase it.
> Is there a super-pressing need for this fix in 3.5.1?

I don't see any urgency.

Comment 10 Sandro Bonazzola 2015-01-15 14:25:34 UTC
This is an automated message: 
This bug should be fixed in oVirt 3.5.1 RC1, moving to QA

Comment 11 Sandro Bonazzola 2015-01-21 16:05:27 UTC
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.