Unable to see multipath devices during rear recover #2451
Assignees
Labels
no-issue-activity
special hardware or VM
The issue depends on non common (virtual) hardware.
support / question
Comments
|
The issue seems to match #2002 using SLES 12 SP3 and rear 2.6 .. i did further testing and using idev commands to reload |
|
@makamp1 Usually @schabrolles is our expert for SAN and multipath on IBM hardware |
|
IMHO this will be one of many FC driver + multipath issues on enterprise grade (I'm guessing HPE Superdome 2 ?) HW. My best guess would be to experiment with driver module options. V. |
|
@makamp1 maybe try to check if your /etc/multipath.conf in ReaR recovery system is the same as on original system. V. |
|
Thank you for the responses.. Issue is on HPE SuperdomeX .. the driver module is included in the RESCUE and get loaded all OK .. just that devices does not get detected when I do multipath -l /etc/multipath.conf in RESCUE mode is same as on original system in the same SAN/Storage environment, small system like DL360 SAN boot sever .. rear recover works fine. sounds some thing to do with the size of the system and number of FC cards in the system and time taken to scan etc .. |
|
The seems to also point in the direction of |
|
anyway to slow it down ? ;-) OR manually scan the devices before kicking off "rear recover" i tried modprobe, multipath -r, udev cmds in rescue shell before ... no luck finding the SAN LUNs |
|
Below is another examoke where I have kept repeating the "rear recover" |
|
I just accidentally run into same behavior on Superdome2 16s x86. V. |
|
@gozora thanks for the update .. when you say "powered off" .. you mean power pulled from the sever OR partition powered off (poweroff partition) for my issue mentioned above, I reduced the partition from 4 blades to 2 blades .. and multipath was able to scan thru all the LUNs fine in rescue shell .. once the rear recovery is completed, and added the blades back to parition and rebooted it. it is more off a workaround than a solution. I wonder how OS Install media would do scan of LUNs in a large system before we get to select the LUN to install the LUN ( I never had issue with OS install on large system ) .. can something like that be implemented in rear rescue ?? |
|
The description in |
|
@makamp1 I am not a HP server user so I know nothing about different boot methods for them. |
I just powered off blade through ILO My Superdome X hardware was in some overall strange state, because it just hanged even during regular OS boot waiting for SAN disks to appear ("thanks" to Systemd compressed boot output format I was not able to see LUN WWN ...), I had to do fuse reset of first blade and after power on system booted just fine. V. |
|
@gozora looks like you had different issue with HW .. and may not be related to REAR @jsmeix I done the reboot of the partition with OS install and rear recover .. no diffrence in there .. if I have a large system/partition, rear rescue's multipath is not able to SCAN the LUNs and prepare them for recovery .. running the udevadm cmds in rescue shell seems to be HIT and MISS in scanning all the LUNs every time. |
jsmeix
added
the
special hardware or VM
|
Only FYI as another mostly blind shot into the dark: Does it perhaps help to zero out the target disk(s) Ideally before the ReaR recovery system is booted Cf. #2019 The current bottom line from that issue is sumarized in the section It seems |
|
Stale issue message |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Relax-and-Recover (ReaR) Issue Template
Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):
ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.6
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
SLES 12 SP4
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
cat /etc/rear/local.conf
Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
BM
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
X86
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
UEFI, GRUB
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
SAN
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):
Description of the issue (ideally so that others can reproduce it):
I am doing some tests to do rear recover of my HPE SuperdomeX server using SLES 12 SP4
When I tried using rear 2.4, during recover multipath devices were not listed "multipath -l"
then I updated it to rear 2.6, it seems to detect the SAN LUNs OK .. but not all of them and miss many LUNs
after few "rear recover" commands are run in the RESCUE mode, the LUNs appear .. and paths go faulty / offline preventing the restore to complete success fully
finally I managed to get 1-2 "rear recover" to work.
below are some outputs
no HW issues are seen as ALL the paths works fine when booted in to OS
PLEASE SEE ATTACHED DOCUMENT WITH DETAILS ON THE CONFIG AND OUTPUTS FROM THE DIFFERENT TESTS
QUESTION
is there any specific configuration required to force detecting SAN/multipath LUNs
Workaround, if any:
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
The text was updated successfully, but these errors were encountered: