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
This is "storage", not "infra". And yes, we should mess with multipath.conf only during installation or via an explicit vdsm-tool command.
(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.
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?
(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.
Returning to NEW - patch was abandonded. Yeela, do you have a different patch for this, as the comment on gerrit suggests?
Yeela, can you please provide some doctext for this bug?
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
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.