#1309 PR `merged`: Multipathing when BOOT_OVER_SAN=y¶

Labels: enhancement, fixed / solved / done

schabrolles opened issue at 2017-04-17 12:15:¶

Force Loading multipath modules when BOOT_OVER_SAN is True. (#1295 re-open)

Before this changes, multipath module was loaded only if multipath devices were present in LAYOUT_FILE.
So, if you migrate from virtual machine (non-multipath) to BOOT_OVER_SAN system (usually multipathed), multipath is not loaded during recover/migration.

I propose to automatically the load of multipath modules during recovery when BOOT_OVER_SAN is True.

I also add /lib*/multipath which where missing when creating rescue image with BOOT_OVER_SAN=y

schabrolles commented at 2017-04-17 12:19:¶

@gdha regarding:

if ! is_true "$BOOT_OVER_SAN" ; then 
  return 
fi

I want the script exit when BOOT_OVER_SAN is false or not set, that's why using is_false is not enough.

jsmeix commented at 2017-04-18 11:15:¶

Regarding
https://github.com/rear/rear/pull/1309#issuecomment-294474190
cf.
https://github.com/rear/rear/pull/1212#issuecomment-283698753
and see the comments for the is_true and is_false functions in
lib/global-functions.sh

I.e.

is_true "$BOOT_OVER_SAN" || return

returns
if BOOT_OVER_SAN is explicitly a 'false' value
and also when BOOT_OVER_SAN is empty
or unset or has another vale like 'foo'
while in contrast

is_false $BOOT_OVER_SAN && return

returns
only if BOOT_OVER_SAN is explicitly a 'false' value
but not when BOOT_OVER_SAN is empty
or unset or has another value like 'foo'.

schabrolles commented at 2017-04-18 11:40:¶

Ok, I like this one :

is_true "$BOOT_OVER_SAN" || return

I'm gonna send an update for review

schlomo commented at 2017-04-19 14:06:¶

@jsmeix just guessing here: If the backup would restore a /etc/multipath.conf then mkrescue should have picked it up already, so that we wouldn't need to create it.

gdha commented at 2017-04-19 14:32:¶

@gozora Just for your info - perhaps you want to add something useful as well (as experienced administrator)?

schabrolles commented at 2017-04-19 15:19:¶

@schlomo

If the backup would restore a /etc/multipath.conf then mkrescue should have picked it up already, so that we wouldn't need to create it.

You are absolutely right.

This is what would happen when you restore the backup on the same machine.
But imagine you have to migrate from a machine (not multipathed, like a VM) to a real baremetal server or PowerVM with Boot_on_San (multipathed) ... You will have to enable the multipath and create a default multipath.conf (for rhel) to detect the NEW disk in multipath before partitioning recreation.

schlomo commented at 2017-04-19 15:24:¶

@schabrolles Yes, I also didn't see right away that we talk about the "migrate to SAN boot" use case here. Of course you are right, maybe worth to hint with comments to the background context.

jsmeix commented at 2017-04-20 13:36:¶

According to
https://github.com/rear/rear/pull/1309#issuecomment-295309240
also @schlomo approves it so that I will merge it
soon if there are no objections...

[Export of Github issue for rear/rear.]

#1309 PR merged: Multipathing when BOOT_OVER_SAN=y¶