----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: "Dan Kenigsberg" <danken@redhat.com>, "users" <users@ovirt.org>, "Yeela Kaplan" <ykaplan@redhat.com>, "Benjamin Marzinski" <bmarzins@redhat.com> Sent: Monday, January 26, 2015 8:46:52 PM Subject: Re: [ovirt-users] Update to 3.5.1 scrambled multipath.conf?
On Mon, Jan 26, 2015 at 1:37 PM, Nir Soffer <nsoffer@redhat.com> wrote:
Any suggestion appreciated.
Current multipath.conf (where I also commented out the getuid_callout that is not used anymore):
[root@tekkaman setup]# cat /etc/multipath.conf # RHEV REVISION 1.1
blacklist { devnode "^(sda|sdb)[0-9]*" }
I think what happened is:
1. 3.5.1 had new multipath version
what do you mean with "new multipath version"?
I mean new multipath.conf version: # RHEV REVISION 1.1 When vdsm finds that its current configuration version is different from current multipath.conf version, it replaces the current multipath.conf with a new version.
I currently have device-mapper-multipath-0.4.9-56.fc20.x86_64 The system came from f18 to f19 and then to f20 via fedup in both cases In my yum.log files I see this about January 2013 when I was in Fedora 18 Jan 07 00:11:44 Installed: device-mapper-multipath-0.4.9-36.fc18.x86_64
I then upgraded to f19 on 24th November 2013 and device-mapper-multipath was the one pushed during the fedup update: device-mapper-multipath-libs-0.4.9-51.fc19.x86_64
Then on 12th of November 2014 I passed form f19 to f20 and fedup pushed device-mapper-multipath-0.4.9-56.fc20.x86_64 that is my current version At that time I also passed from oVirt 3.4.4 to 3.5.0. And I didn't register any problem with my internal disk
It was sufficient to keep inside blacklist { devnode "sd[a-b]" }
At the head of the file I only had: # RHEV REVISION 1.0
This is why vdsm replaced the file.
No reference about # RHEV PRIVATE
But right now that I'm writing I notice that my rule for blacklist after migration to 3.5.1 was
devnode "^(sda|sdb)[0-9]*"
probably blacklists only partitions and not the full disks.... ;-) So I'm going to check with the old blacklist option and/or the PRIVATE label as suggested by Dan...
Probably passing from RHEV REVISION 1.0 to 1.1 the original blacklist part was thrown away...
2. So vdsm upgraded the local file
3. blacklist above was removed (it should exists in /etc/multipath.bak)
It seems it didn't generate any multipath.conf.bak ...
In 3.5.1 it should rotate multipath.conf, saving multipath.conf.1 ... If you don't find the backup file after multipath.conf was updated, this is a bug. Can you open a a bug about it? Nir