[ovirt-users] Update to 3.5.1 scrambled multipath.conf?

[Nir Soffer]

----- Original Message -----
> From: "Gianluca Cecchi" <gianluca.cecchi at gmail.com>
> To: "Nir Soffer" <nsoffer at redhat.com>
> Cc: "Dan Kenigsberg" <danken at redhat.com>, "users" <users at ovirt.org>, "Yeela Kaplan" <ykaplan at redhat.com>, "Benjamin
> Marzinski" <bmarzins at 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 at redhat.com> wrote:
> 
> >
> > > > Any suggestion appreciated.
> > > >
> > > > Current multipath.conf (where I also commented out the getuid_callout
> > that
> > > > is not used anymore):
> > > >
> > > > [root at 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