Bug 1076531 - vdsm overwrites multipath.conf at every startup if vdsm installed file was replaced
vdsm overwrites multipath.conf at every startup if vdsm installed file was re...
Status: CLOSED CURRENTRELEASE
Product: oVirt
Classification: Community
Component: vdsm (Show other bugs)
3.3
Unspecified Unspecified
unspecified Severity unspecified
: m1
: 3.6.0
Assigned To: Yeela Kaplan
Elad
storage
:
Depends On:
Blocks: 1108711
  Show dependency treegraph
 
Reported: 2014-03-14 09:52 EDT by Enrico Tagliavini
Modified: 2016-03-10 01:14 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: multipath is reconfigured on each vdsm service restart. Consequence: multipath.conf should not be changed since important changes done by the sysadmin are needed and might be overwritten. Fix: vdsm will fail to start if multipath configuration is required. Multipath will be reconfigured only on user demand using "vdsm-tool configure --module multipath".
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-04 07:59:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 30909 master MERGED Move multipath configuration to vdsm-tool configurator Never

  None (edit)
Description Enrico Tagliavini 2014-03-14 09:52:00 EDT
Environment:
CentOS 6.5, fresh install. The storage is an SGI Infinistorage 5000 connected via SAS to 2 servers. oVirt 3.3 fresh install as well also on the engine side. This is the first and only datacenter / cluster configured.

Multipath was configured automatically during install. LUNs where autodetected and multipath.conf correctly generated by anaconda. I've applied minor customisations for more friendly names, that's all.

Description of problem:
When service vdsm is started multipath.conf is overwritten with a non working version (for this storage configuration). This happens at every vdsmd service start, unless the first 2 lines of multipath.conf are:

# RHEV REVISION 1.0
# RHEV PRIVATE
this was found looking at the code in /usr/share/vdsm/storage/multipath.py

Version-Release number of selected component (if applicable):
CentOS 6.5
oVirt 3.3.4
device-mapper-multipath 0.4.9-72
vdsm 4.13.3-4


Steps to Reproduce:
1. Make some change to multipath.conf
2. configure the host in the oVirt manager web interface (if not already configured)
3. restart vdsmd or reboot the node.

Actual results:
multipath.conf is changed

Expected results:
multipath.conf should not be changed since important changes done by the system administrator might be overwritten and needed for a working configuration
Comment 1 Dan Kenigsberg 2014-03-16 20:00:06 EDT
This is "storage", not "infra". And yes, we should mess with multipath.conf only during installation or via an explicit vdsm-tool command.
Comment 2 Nir Soffer 2014-07-25 18:43:53 EDT
(In reply to Enrico Tagliavini from comment #0)
> Description of problem:
> When service vdsm is started multipath.conf is overwritten with a non
> working version (for this storage configuration).

Vdsm depends on the configuration it provides, we cannot avoid installing our own configuration since on most machines this is the correct configuration.

The user configuration is kept by rotating the configuration file.

> This happens at every
> vdsmd service start, unless the first 2 lines of multipath.conf are:
> 
> # RHEV REVISION 1.0
> # RHEV PRIVATE

Exactly, if you replace the configuration with you own file, vdsm will 
replace it with its own file. But if you edit vdsm generated file with 
your changes, vdsm will not touch your file.

So I think there is no bug here, and this should be closed.

We can convert this to RFE, improving the way we configure multipath:

1. Document how the configuration work in the top of the file. The admin
   should not look in vdsm code to understand how to modify multipath
   configuration without getting them overwritten by vdsm.

2. Add vdsm specific setting to existing user file instead of overwriting
   the admin file. Not sure how easy is this.

3. Move the configuration from vdsm startup to vdsm-tool, giving more
   control to the admin. For example, vdsm can fail with verbose error 
   message if it cannot configure the user file.

4. Vdsm should check current multipath configuration and fail to start
   if the configuration is not compatible with vdsm. This change is 
   required if we move the configuration to vdsm-tool.
Comment 3 Enrico Tagliavini 2014-07-25 18:54:56 EDT
Hi Nir,

yes as you said 1. is the main problem, I had to look at the python code to sort it out. Adding a comment at the top of the file is very very helpful and very easy to implement I suppose.

2. This is going to be tricky and fragile, and likely not worth the effort anyway, 3. and 4. looks better

3. and 4. this is a good idea. You don't expect a service to change a config file every time it starts up, it is unusual and confusing. Configuring it once automatically when the node is added to the oVirt cluster would be a better idea. A command for the admin can be provided in vdsm-tool if the config file needs to be regenerated.

And if I can add my own:

5. What about also improving the autodetection? The anaconda installer did it right, the oVirt config did not. Some code that can be reused maybe?
Comment 4 Nir Soffer 2014-07-25 19:23:08 EDT
(In reply to Enrico Tagliavini from comment #3)
> Hi Nir,
> 
> yes as you said 1. is the main problem, I had to look at the python code to
> sort it out. Adding a comment at the top of the file is very very helpful
> and very easy to implement I suppose.
> 
> 2. This is going to be tricky and fragile, and likely not worth the effort
> anyway, 3. and 4. looks better
> 
> 3. and 4. this is a good idea. You don't expect a service to change a config
> file every time it starts up, it is unusual and confusing. Configuring it
> once automatically when the node is added to the oVirt cluster would be a
> better idea. A command for the admin can be provided in vdsm-tool if the
> config file needs to be regenerated.
> 
> And if I can add my own:
> 
> 5. What about also improving the autodetection? The anaconda installer did
> it right, the oVirt config did not. Some code that can be reused maybe?

I suggest that we discuss this in the mailing list, or if you can describe how it should work, please open a separate bug for this.
Comment 5 Allon Mureinik 2014-08-03 02:12:03 EDT
Returning to NEW - patch was abandonded.

Yeela, do you have a different patch for this, as the comment on gerrit suggests?
Comment 6 Allon Mureinik 2015-03-29 14:30:14 EDT
Yeela, can you please provide some doctext for this bug?
Comment 9 Elad 2015-04-21 04:08:48 EDT
vdsm doesn't override changes made in multipath.conf after vdsm service restart or a reboot.

Verified using 3.6.0-1
vdsm-4.17.0-632.git19a83a2.el7.x86_64
device-mapper-multipath-0.4.9-77.el7.x86_64
Comment 10 Sandro Bonazzola 2015-11-04 07:59:36 EST
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue.
If problems still persist, please open a new BZ and reference this one.

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