dup mpath?

dup mpath?

[Domenico Viggiani]

Hi,
what's the exact meaning of these messages:

 # multipath -v2    
 remove: mpath9 (dup of mpath1)
 mpath9: map in use
 remove: mpath13 (dup of mpath2)
 mpath13: map in use

?
If mpath9/13 already exist, why does multipath try to create mpath1/2?

System (RH 4.5) is just rebooted, storage is EMC Clariion CX700.
LVM is in use.

Thanks
--
DV

Re: dup mpath?

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Domenico Viggiani wrote:
> Hi,
> what's the exact meaning of these messages:
> 
>  # multipath -v2    
>  remove: mpath9 (dup of mpath1)
>  mpath9: map in use
>  remove: mpath13 (dup of mpath2)
>  mpath13: map in use
> 
> ?
> If mpath9/13 already exist, why does multipath try to create mpath1/2?
> 
> System (RH 4.5) is just rebooted, storage is EMC Clariion CX700.
> LVM is in use.

Looks like you have a problem with your bindings
(/var/lib/mpath/bindings). This can happen if, for e.g. the /var tree is
a separate file system.

In this case, multipath devices are created by rc.sysinit before /var is
mounted. Later on, if the wwid to mpath names in the bindings file are
different from those that mpath auto-detected in rc.sysinit you end up
with conflicts like this - multipath is trying to re-name the mpath
devices according to the entries in the bindings file.

If LVM has already activated volume groups on the devices this gives you
the "map in use" errors you noted above.

See this bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=320151

There are a couple of workarounds you can use: make /var part of the
root file system, configure your bindings via /etc/multipath.conf
instead (use device { /* ... */ wwid = } blocks), or copy the bindings
file from the /var file system into a location named
/var/lib/mpath/bindings on the root file system (although I would not
recommend this last option as it can become confusing).

Kind regards,
Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHD3RP6YSQoMYUY94RAhqMAKC33LKJBCK5R7RFhk8pkixTMzOB+gCfbE6y
Nb2C5vqHipk9lVXyoudOOMI=
=aUoK
-----END PGP SIGNATURE-----

Re: dup mpath?

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bryn M. Reeves wrote:
> There are a couple of workarounds you can use: make /var part of the
> root file system, configure your bindings via /etc/multipath.conf
> instead (use device { /* ... */ wwid = } blocks), or copy the bindings
> file from the /var file system into a location named
> /var/lib/mpath/bindings on the root file system (although I would not
> recommend this last option as it can become confusing).

Blech - I meant "multipath" blocks, not "device" blocks, e.g., putting
something like this into multipath.conf:

multipaths {
    multipath {
        wwid 360060480000190102501530123456789
        alias  mpath0
    }

    multipath {
        wwid    360060480000190102501530123456799
        alias   mpath1
    }
}

Kind regards,
Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHD3aW6YSQoMYUY94RArcjAJ9H7fPbMfoaCK+v0HlVISrF8lLhnwCg1FTB
goQimrLbcWfNoh526bkEyGo=
=ynBE
-----END PGP SIGNATURE-----

RE: dup mpath?

[Domenico Viggiani]

> Looks like you have a problem with your bindings 
> (/var/lib/mpath/bindings). This can happen if, for e.g. the 
> /var tree is a separate file system.
> 
> In this case, multipath devices are created by rc.sysinit 
> before /var is mounted. Later on, if the wwid to mpath names 
> in the bindings file are different from those that mpath 
> auto-detected in rc.sysinit you end up with conflicts like 
> this - multipath is trying to re-name the mpath devices 
> according to the entries in the bindings file.
> 
> If LVM has already activated volume groups on the devices 
> this gives you the "map in use" errors you noted above.
> 
> See this bugzilla:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=320151

It's amazing the way you answer me with this wonderful description of the
problem after only a few tens of minutes while regular Red Hat support is
struggling with my call since many days!
In my opinion, this is a limit to the adoption of Linux in the enterprise
environment: it needs too technical involvement from specialized personnel.
I hope that Red Hat will understand that it needs more expert engineers in
the frontline.

Heartfelt thanks and sorry for my bad english
..
Domenico Viggiani