mpath Fehler "error getting device [EBUSY]" nach 7to8 Update

Kleif · Jul 25, 2024

Guten Tag,

nach dem Update von PVE 7 zu 8 ist aufgefallen, dass bestimmter SAN Speicher nicht mehr zur Verfügung steht.
Zwei SAN Speicher sind über 2 mpaths (mpath0 und mpath1) konfiguriert. Nun stellte sich heraus, dass mpath0 weiterhin verbunden ist und läuft.
mpath1 hingegen lässt sich nur im debug einsehen. Sämtliche logs lassen nur darauf schließen, dass das Gerät busy ist.
Das Ganze passiert offensichtlich sobald der multipathd läuft, also ab boot.
Alle Versuche über lvm zu agieren scheitern schon daran, dass das physical volume nicht verfügbar ist.
Ich kann mir vorstellen, dass es eine Racecondition zwischen dem multipathd und lvm beim booten gibt. Momentan komme ich aber nicht wirklich weiter, da ich das System auch nicht munter hoch und runterfahren kann.

multipath -ll

Code:

mpath0 () dm-14
size=21T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| |- 11:0:0:0 sdc 8:32  active ready running
| `- 13:0:0:0 sdg 8:96  active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
  |- 12:0:0:0 sde 8:64  active ready running
  `- 14:0:0:0 sdi 8:128 active ready running

multipath -d

Code:

: mpath1 () undef
size=9.6T features='1 queue_if_no_path' hwhandler='1 alua' wp=undef
|-+- policy='round-robin 0' prio=50 status=undef
| |- 12:0:0:1 sdf 8:80  undef ready running
| `- 14:0:0:1 sdj 8:144 undef ready running
`-+- policy='round-robin 0' prio=10 status=undef
  |- 11:0:0:1 sdd 8:48  undef ready running
  `- 13:0:0:1 sdh 8:112 undef ready running

journalctl -u multipathd

Code:

Feb 27 10:50:00 Proxmox systemd[1]: Starting Device-Mapper Multipath Device Controller...
Feb 27 10:50:00 Proxmox multipathd[1464]: --------start up--------
Feb 27 10:50:00 Proxmox multipathd[1464]: read /etc/multipath.conf
Feb 27 10:50:00 Proxmox multipathd[1464]: path checkers start up
Feb 27 10:50:00 Proxmox multipathd[1464]: failed to increase buffer size
Feb 27 10:50:00 Proxmox multipathd[1464]: mpath0: addmap [0 44711280640 multipath 1 queue_if_no_path 1 alua 2 1 round-robin 0 2 1 8:32 1 8:96 1 round-robin 0 2 1 8:64 1 8:128 1]
Feb 27 10:50:00 Proxmox multipathd[1464]: mpath1: addmap [0 20635975680 multipath 1 queue_if_no_path 1 alua 2 1 round-robin 0 2 1 8:80 1 8:144 1 round-robin 0 2 1 8:48 1 8:112 1]
Feb 27 10:50:00 Proxmox systemd[1]: Started Device-Mapper Multipath Device Controller.
Feb 27 11:10:56 Proxmox multipathd[1464]: mpath1: removing map by alias
Feb 27 11:10:57 Proxmox multipathd[1464]: dm-9: devmap not registered, can't remove
Feb 27 11:11:15 Proxmox multipathd[1464]: exit (signal)
Feb 27 11:11:15 Proxmox systemd[1]: Stopping Device-Mapper Multipath Device Controller...
Feb 27 11:11:16 Proxmox multipathd[1464]: --------shut down-------
Feb 27 11:11:16 Proxmox systemd[1]: multipathd.service: Succeeded.
Feb 27 11:11:16 Proxmox systemd[1]: Stopped Device-Mapper Multipath Device Controller.

dmesg | grep -i "multipath"

Code:

[   18.046720] systemd[1]: Listening on multipathd.socket - multipathd control socket.
[   18.089390] systemd[1]: Starting multipathd.service - Device-Mapper Multipath Device Controller...
[   18.834222] device-mapper: multipath round-robin: version 1.2.0 loaded
[   18.873705] device-mapper: table: 252:15: multipath: error getting device (-EBUSY)
[   18.879093] device-mapper: table: 252:15: multipath: error getting device (-EBUSY)
[   18.880444] device-mapper: table: 252:15: multipath: error getting device (-EBUSY)
[   18.881673] device-mapper: table: 252:15: multipath: error getting device (-EBUSY)

lsblk

Code:

NAME                MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                   8:0    0 446.6G  0 disk 
├─sda1                8:1    0  1007K  0 part 
├─sda2                8:2    0   512M  0 part 
└─sda3                8:3    0 444.5G  0 part 
  ├─pve-swap        252:0    0    48G  0 lvm   [SWAP]
  ├─pve-root        252:1    0    20G  0 lvm   /
  ├─pve-data_tmeta  252:2    0   3.6G  0 lvm  
  └─pve-data_tdata  252:3    0 349.4G  0 lvm  

sdb                   8:16   0   7.3T  0 disk 
└─sdb1                8:17   0   7.3T  0 part  /mnt/pve/Server-RAID6
sdc                   8:32   0  20.8T  0 disk 
└─mpath0            252:14   0  20.8T  0 mpath
  ├─mpath0-part1    252:15   0   128M  0 part 
  └─mpath0-part2    252:16   0  20.8T  0 part 
sdd                   8:48   0   9.6T  0 disk 
└─sdd1                8:49   0   9.6T  0 part 
  ├─Storage--RAID6-vm--103--disk--0
  │                 252:8    0   1.8T  0 lvm  
  ├─Storage--RAID6-Storage_tmeta
  │                 252:9    0     2G  0 lvm  
  │ └─Storage--RAID6-Storage-tpool
  │                 252:11   0   7.8T  0 lvm  
  │   ├─Storage--RAID6-Storage
  │   │             252:12   0   7.8T  1 lvm  
  │   └─Storage--RAID6-vm--103--disk--1
  │                 252:13   0   3.7T  0 lvm  
  └─Storage--RAID6-Storage_tdata
                    252:10   0   7.8T  0 lvm  
    └─Storage--RAID6-Storage-tpool
                    252:11   0   7.8T  0 lvm  
      ├─Storage--RAID6-Storage
      │             252:12   0   7.8T  1 lvm  
      └─Storage--RAID6-vm--103--disk--1
                    252:13   0   3.7T  0 lvm  
sde                   8:64   0  20.8T  0 disk 
└─mpath0            252:14   0  20.8T  0 mpath
  ├─mpath0-part1    252:15   0   128M  0 part 
  └─mpath0-part2    252:16   0  20.8T  0 part 
sdf                   8:80   0   9.6T  0 disk 
└─sdf1                8:81   0   9.6T  0 part 
sdg                   8:96   0  20.8T  0 disk 
└─mpath0            252:14   0  20.8T  0 mpath
  ├─mpath0-part1    252:15   0   128M  0 part 
  └─mpath0-part2    252:16   0  20.8T  0 part 
sdh                   8:112  0   9.6T  0 disk 
└─sdh1                8:113  0   9.6T  0 part 
sdi                   8:128  0  20.8T  0 disk 
└─mpath0            252:14   0  20.8T  0 mpath
  ├─mpath0-part1    252:15   0   128M  0 part 
  └─mpath0-part2    252:16   0  20.8T  0 part 
sdj                   8:144  0   9.6T  0 disk 
└─sdj1                8:145  0   9.6T  0 part

Falk R. · Jul 26, 2024

Hi, was für ein Storage ist das und wie ist es angebunden? FC / SAS / iSCSI?

devaux · Aug 3, 2024

Selbes Problem aus heiterem Himmel. HPE MSA2040 an FC und 2 Hosts. Ein Host laeuft momentan noch. Der andere meldet immer Fehler wegen Device Busy. Habe auch mit aelterem 6.5-er Kernel probiert.

Falk R. · Aug 3, 2024

Ich glaube nicht, dass es am Multipath liegt. Der ist nur Leidtragender.
Welchen Host Typ nutzt du? Ich vermute Probleme mit den SCSI Reservations.

devaux · Aug 3, 2024

Hey, vielen Dank fuer die prompte Antwort!
Was meinst Du genau mit Host Typ? Ich habe es nach dem Howto hier eingerichtet: https://pve.proxmox.com/wiki/ISCSI_Multipath
Auch kann ich die LVMs sehen. Allerdings nicht den Besagten "252:30" aus dem Error

dmsetup ls --tree -o blkdevname
pve-data <dm-5> (252:5)
└─pve-data-tpool <dm-4> (252:4)
├─pve-data_tdata <dm-3> (252:3)
│ └─ <sda3> (8:3)
└─pve-data_tmeta <dm-2> (252:2)
└─ <sda3> (8:3)
pve-root <dm-1> (252:1)
└─ <sda3> (8:3)
pve-swap <dm-0> (252:0)
└─ <sda3> (8:3)
pve-vm--104--disk--0 <dm-6> (252:6)
└─pve-data-tpool <dm-4> (252:4)
├─pve-data_tdata <dm-3> (252:3)
│ └─ <sda3> (8:3)
└─pve-data_tmeta <dm-2> (252:2)
└─ <sda3> (8:3)
san_dg01_lvm-vm--100--disk--0 <dm-10> (252:10)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--101--disk--0 <dm-9> (252:9)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--102--disk--0 <dm-11> (252:11)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--105--disk--0 <dm-12> (252:12)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--105--disk--1 <dm-27> (252:27)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--106--disk--0 <dm-13> (252:13)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--106--disk--1 <dm-14> (252:14)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--107--disk--0 <dm-15> (252:15)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--108--disk--0 <dm-16> (252:16)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--109--disk--0 <dm-17> (252:17)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--109--disk--1 <dm-18> (252:18)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--110--disk--0 <dm-19> (252:19)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--111--disk--0 <dm-20> (252:20)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--111--disk--1 <dm-21> (252:21)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--113--disk--0 <dm-22> (252:22)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--114--disk--0 <dm-23> (252:23)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--114--disk--1 <dm-24> (252:24)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--114--disk--2 <dm-25> (252:25)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--114--disk--3 <dm-26> (252:26)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--115--disk--0 <dm-29> (252:29)
└─ <sdd1> (8:49)
san_dg01_lvm-vm--115--disk--1 <dm-28> (252:28)
└─ <sdd1> (8:49)
san_dg02_lvm-vm--103--disk--0 <dm-7> (252:7)
└─ <sdc1> (8:33)
san_dg02_lvm-vm--112--disk--0 <dm-8> (252:8)
└─ <sdc1> (8:33)

Ich glaube "252:30" gibt es gar nicht (mehr).
Kann ich diesen Bezug irgengwie manuell loeschen?

devaux · Aug 4, 2024

Ja, scheint wirklich ein Problem mit den IDs zu haben. Habe jetzt vom funktionierenden Host eine weitere Disk erstellt und nun verursacht nicht mehr "252:30", sondern "252:31" den Fehler.
Wie loese ich das am Besten?

# pvesm status
Command failed with status code 5.
command '/sbin/vgscan --ignorelockingfailure --mknodes' failed: exit code 5
Name Type Status Total Used Available %
local dir active 81564080 9485488 67889408 11.63%
local-lvm lvmthin active 179597312 51400750 128196561 28.62%
nuagsyn02 nfs active 44971327488 31913958400 13057369088 70.97%
pbs_nuagsyn02 pbs active 44971327488 31913958400 13057369088 70.97%
san_dg01_lvm lvm inactive 0 0 0 0.00%
san_dg02_lvm lvm inactive 0 0 0 0.00%

Falk R. · Aug 4, 2024

Guck mal auf dem Storage welchen Hosttyp du angegeben hast. Ich habe länger keine MSA mehr in der Hand gehabt und weiß auch nicht mehr die Defaults. Das Storage muss wissen, dass da ein Cluster zugreift, bei manchen locking Mechanismen. Es kann gut sein, dass auch im Linux Kernel neue Features rein gekommen sind. ESXi hat früher auch mit einfachen SCSI reservations gearbeitet und heutzutage Atomic Testing.
Wie das im Linux und im verwendeten FC Karten Treiber gehandhabt wird, weiß ich auch nicht.

devaux · Aug 4, 2024

Hmm. Hab momentan leider keinen Zugriff auf das SAN. Werde wohl "morgen" vor Ort gehen muessen. Oder sehe ich das vom noch laufenden Host? Meines Wissens gibt man auf dem SAN einfach die IDs der FC-Karten auf den Hosts frei und kann dann zugreifen.
Ich denke das Problem liegt aber wie von Dir erwaehnt in einem fehlenden/falschen Verweis auf ein LVM Volume welches nicht mehr existiert. Diese sind naemlich alle vorhanden, aber dieses 252:30 fehlt und laesst es wohl nicht zu, dass die LVM in Proxmox erscheinen.

# blkid
/dev/mapper/pve-root: UUID="ab2404e7-af24-44ac-a731-a1f739e088f0" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sdd1: UUID="x37AQB-R7dv-cv2i-Njid-HyyH-rYrq-ie6cpm" TYPE="LVM2_member" PARTUUID="75152461-e1d2-4994-a356-b1b67e39c176"
/dev/sdb1: UUID="x37AQB-R7dv-cv2i-Njid-HyyH-rYrq-ie6cpm" TYPE="LVM2_member" PARTUUID="75152461-e1d2-4994-a356-b1b67e39c176"
/dev/mapper/pve-swap: UUID="52a47879-5506-46e5-9191-0ebf8fd59490" TYPE="swap"
/dev/sde1: UUID="xaxXID-CYaI-DchL-Mlwz-gpdH-QRzS-CGHkMR" TYPE="LVM2_member" PARTUUID="06e1fd37-54ab-4898-a692-b944f690352c"
/dev/sdc1: UUID="xaxXID-CYaI-DchL-Mlwz-gpdH-QRzS-CGHkMR" TYPE="LVM2_member" PARTUUID="06e1fd37-54ab-4898-a692-b944f690352c"
/dev/sda2: UUID="DE3C-6C54" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="7be0d940-7181-4726-bb0e-985e094a2518"
/dev/sda3: UUID="dzTvFk-l0Rd-H4Vo-NaIq-ZOZS-o3HG-sJkimv" TYPE="LVM2_member" PARTUUID="5235d970-8485-4eed-8a48-d22e8f08aef1"
/dev/mapper/san_dg01_lvm-vm--111--disk--0: PTUUID="61433f3c" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--100--disk--0: PTUUID="26494cf2" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--115--disk--0: PTUUID="1db0112e" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--110--disk--0: PTUUID="c6859c22" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--105--disk--1: PTUUID="1db0112e" PTTYPE="dos"
/dev/mapper/san_dg02_lvm-vm--112--disk--0: PTUUID="ac5c8f85" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--109--disk--0: PTUUID="2b9f4a7f" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--114--disk--2: PTUUID="a2187f73-20a5-439e-8d80-3c419870e94e" PTTYPE="gpt"
/dev/mapper/pve-vm--104--disk--0: PTUUID="57af9fc6-d687-4bdf-85bf-d225ab83841a" PTTYPE="gpt"
/dev/mapper/san_dg01_lvm-vm--107--disk--0: PTUUID="3384d0f1" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--111--disk--1: PTUUID="55e2aac1" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--102--disk--0: PTUUID="000ed7e3" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--115--disk--1: PTUUID="b928429d" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--101--disk--0: PTUUID="01925a50-697c-4a41-b7ae-b7d9760ba84a" PTTYPE="gpt"
/dev/mapper/san_dg01_lvm-vm--109--disk--1: PTUUID="64f44744" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--114--disk--3: PTUUID="5d99e4d0-6f34-4812-922d-0d419ebbd33f" PTTYPE="gpt"
/dev/mapper/san_dg02_lvm-vm--103--disk--0: PTUUID="f3b39566" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--108--disk--0: PTUUID="6e18edf2" PTTYPE="dos"
/dev/sda1: PARTUUID="54600aff-f21e-4bfd-9573-3e032b81ce18"
/dev/mapper/san_dg01_lvm-vm--114--disk--1: PTUUID="14d91123-5bb3-48e7-a3ce-5a51568503b2" PTTYPE="gpt"
/dev/mapper/san_dg01_lvm-vm--106--disk--1: PTUUID="de6f9964-5563-4aab-a856-7f97f56a7858" PTTYPE="gpt"
/dev/mapper/san_dg01_lvm-vm--113--disk--0: PTUUID="1db0112e" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--105--disk--0: PTUUID="57719800" PTTYPE="dos"
root@bfbvm01:/dev/mapper# blkid | grep 115
/dev/mapper/san_dg01_lvm-vm--115--disk--0: PTUUID="1db0112e" PTTYPE="dos"
/dev/mapper/san_dg01_lvm-vm--115--disk--1: PTUUID="b928429d" PTTYPE="dos"

# ls -l /dev/mapper/
insgesamt 0
crw------- 1 root root 10, 236 4. Aug 00:58 control
lrwxrwxrwx 1 root root 7 4. Aug 00:58 pve-data -> ../dm-5
lrwxrwxrwx 1 root root 7 4. Aug 00:58 pve-data_tdata -> ../dm-3
lrwxrwxrwx 1 root root 7 4. Aug 00:58 pve-data_tmeta -> ../dm-2
lrwxrwxrwx 1 root root 7 4. Aug 00:58 pve-data-tpool -> ../dm-4
lrwxrwxrwx 1 root root 7 4. Aug 00:58 pve-root -> ../dm-1
lrwxrwxrwx 1 root root 7 4. Aug 00:58 pve-swap -> ../dm-0
lrwxrwxrwx 1 root root 7 4. Aug 00:58 pve-vm--104--disk--0 -> ../dm-6
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--100--disk--0 -> ../dm-10
lrwxrwxrwx 1 root root 7 4. Aug 00:58 san_dg01_lvm-vm--101--disk--0 -> ../dm-9
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--102--disk--0 -> ../dm-11
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--105--disk--0 -> ../dm-12
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--105--disk--1 -> ../dm-27
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--106--disk--0 -> ../dm-13
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--106--disk--1 -> ../dm-14
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--107--disk--0 -> ../dm-15
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--108--disk--0 -> ../dm-16
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--109--disk--0 -> ../dm-17
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--109--disk--1 -> ../dm-18
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--110--disk--0 -> ../dm-19
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--111--disk--0 -> ../dm-20
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--111--disk--1 -> ../dm-21
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--113--disk--0 -> ../dm-22
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--114--disk--0 -> ../dm-23
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--114--disk--1 -> ../dm-24
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--114--disk--2 -> ../dm-25
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--114--disk--3 -> ../dm-26
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--115--disk--0 -> ../dm-29
lrwxrwxrwx 1 root root 8 4. Aug 00:58 san_dg01_lvm-vm--115--disk--1 -> ../dm-28
lrwxrwxrwx 1 root root 7 4. Aug 00:58 san_dg02_lvm-vm--103--disk--0 -> ../dm-7
lrwxrwxrwx 1 root root 7 4. Aug 00:58 san_dg02_lvm-vm--112--disk--0 -> ../dm-8

devaux · Aug 4, 2024

Zum Vergleich. Auf dem funktionierenden Host sind die Thick-LVMs vorhanden:

# ls -l /dev/mapper
insgesamt 0
crw------- 1 root root 10, 236 7. Jun 16:18 control
lrwxrwxrwx 1 root root 7 7. Jun 16:48 pve-data -> ../dm-9
lrwxrwxrwx 1 root root 7 7. Jun 16:48 pve-data_tdata -> ../dm-3
lrwxrwxrwx 1 root root 7 7. Jun 16:48 pve-data_tmeta -> ../dm-2
lrwxrwxrwx 1 root root 7 7. Jun 16:48 pve-data-tpool -> ../dm-4
lrwxrwxrwx 1 root root 7 7. Jun 16:18 pve-root -> ../dm-1
lrwxrwxrwx 1 root root 7 7. Jun 16:18 pve-swap -> ../dm-0
lrwxrwxrwx 1 root root 7 7. Jun 16:28 san_dg01_lvm -> ../dm-5
lrwxrwxrwx 1 root root 7 4. Aug 00:43 san_dg01_lvm-part1 -> ../dm-7
lrwxrwxrwx 1 root root 8 3. Aug 21:50 san_dg01_lvm-vm--101--disk--0 -> ../dm-21
lrwxrwxrwx 1 root root 8 2. Aug 22:30 san_dg01_lvm-vm--102--disk--0 -> ../dm-20
lrwxrwxrwx 1 root root 8 6. Jul 03:04 san_dg01_lvm-vm--105--disk--1 -> ../dm-16
lrwxrwxrwx 1 root root 8 2. Aug 22:40 san_dg01_lvm-vm--107--disk--0 -> ../dm-12
lrwxrwxrwx 1 root root 8 2. Aug 23:05 san_dg01_lvm-vm--108--disk--0 -> ../dm-13
lrwxrwxrwx 1 root root 8 2. Aug 23:46 san_dg01_lvm-vm--109--disk--0 -> ../dm-14
lrwxrwxrwx 1 root root 8 2. Aug 23:46 san_dg01_lvm-vm--109--disk--1 -> ../dm-15
lrwxrwxrwx 1 root root 8 3. Aug 00:06 san_dg01_lvm-vm--113--disk--0 -> ../dm-17
lrwxrwxrwx 1 root root 8 3. Aug 00:17 san_dg01_lvm-vm--115--disk--0 -> ../dm-18
lrwxrwxrwx 1 root root 8 3. Aug 00:17 san_dg01_lvm-vm--115--disk--1 -> ../dm-19
lrwxrwxrwx 1 root root 7 7. Jun 16:28 san_dg02_lvm -> ../dm-6
lrwxrwxrwx 1 root root 7 12. Jun 20:05 san_dg02_lvm-part1 -> ../dm-8
lrwxrwxrwx 1 root root 8 2. Aug 22:37 san_dg02_lvm-vm--103--disk--0 -> ../dm-11
lrwxrwxrwx 1 root root 8 2. Aug 23:46 san_dg02_lvm-vm--112--disk--0 -> ../dm-10

Auch sind auf dem "defekten" host die Devices im /dev/disk/by-id/ Pfad vorhanden:

# ls -l /dev/disk/by-id/scsi-SHP_MSA_2040_SAN_00c0ff*
lrwxrwxrwx 1 root root 9 4. Aug 02:21 /dev/disk/by-id/scsi-SHP_MSA_2040_SAN_00c0ff1e3bcf00000fe6626601000000 -> ../../sdb
lrwxrwxrwx 1 root root 10 4. Aug 02:21 /dev/disk/by-id/scsi-SHP_MSA_2040_SAN_00c0ff1e3bcf00000fe6626601000000-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 9 4. Aug 00:58 /dev/disk/by-id/scsi-SHP_MSA_2040_SAN_00c0ff27c74c0000bed3626601000000 -> ../../sde
lrwxrwxrwx 1 root root 10 4. Aug 00:58 /dev/disk/by-id/scsi-SHP_MSA_2040_SAN_00c0ff27c74c0000bed3626601000000-part1 -> ../../sde1

devaux · Aug 4, 2024

Update. Neuinstallation der problematischen Node hat nicht geholfen. Selbes Problem. Werde dann wohl doch dem SAN einen Besuch abstatten. Auch wenn ich noch nicht ganz genau weiss wonach ich suchen soll.

Falk R. · Aug 4, 2024

devaux said:
Update. Neuinstallation der problematischen Node hat nicht geholfen. Selbes Problem. Werde dann wohl doch dem SAN einen Besuch abstatten. Auch wenn ich noch nicht ganz genau weiss wonach ich suchen soll.

Schreib mir mal oder Screenshot der Einstellungen bei den Hosts.

devaux · Aug 4, 2024

Funktionierend:

Nicht funktionierend:

Lustigerweise ist das Standard LVM "pve" auch nicht da.

Falk R. · Aug 4, 2024

vermutlich hängt der ganze Storage Stack auf dem Node, weil er nicht zugreifen darf.
Deshalb wäre es wichtig zu wissen, ob das Storage weiß, dass dies Clusternodes sind die simultan zugreifen dürfen.

devaux · Aug 4, 2024

Ich glaube, ich konnte es loesen:
Irgendwas stimmte mit den LVM-Filtern nicht. Nachdem ich diesen Filter in /etc/lvm/lvm.conf definiert hatte, konnte multipath die Geraete wieder erstellen:

Code:

filter = [ "a|/dev/mapper/|", "a|/dev/sda.*|", "r|.*|" ]

Das komisch ist, dass dieser Eintrag vorher nicht noetig war und auch auf dem noch funktionierenden Host nicht in der Config ist.
Ich habe diesen jetzt vorsichtshalber auf allen Hosts nachgefuehrt.

Falk R. · Aug 4, 2024

Was ist den /dev/sda auf dem Host?

devaux · Aug 4, 2024

sda ist das lokale RAID1 auf dem Proxmox installiert wird. Da wird ja standardmaessig auch ein LVM gemacht, wenn man die "normale" Installation ohne ZFS macht.

Falk R. · Aug 4, 2024

Wenn das deine Systemdisk ist und du dafür einen Filter setzt, kommt mir das auch komisch vor. Außerdem müsste dann das lokale LVM-Thin offline sein.
Hast du die lokale disk in deiner Multipath Konfiguration geblacklistet?

devaux · Aug 4, 2024

Ja, in multipath ist nur die beiden FC-SCSI devices wwids gewhitelistet. Alles andere ist in der blacklist.
Im LVM-Filter ist alles blockiert ausser /dev/sda* (LVM-thin) und /dev/mapper/*

Falk R. · Aug 5, 2024

Mich wundert nur, dass dieses Problem plötzlich aufgetaucht ist.
Ich wüsste natürlich gern warum, damit ich beurteilen kann ob eventuell ein generelles Problem da ist.

devaux · Aug 5, 2024

Exakt. Leider habe ich wegen dem Eifer im Gefecht (und der Neuinstallation) des Hosts die genauen Logfiles nicht mehr und weiss deshalb nicht WAS das Problem ausgeloest hat - und ob es rein Zufall war oder der Filter-Eintrag wirklich die Loesung ist.

War es ein Update welches auf dem Host eingespielt - aber noch nicht aktiviert wurde - oder wirklich eine "spezielle" Konstellation mit dem LVMs?
Fakt ist, dass es auf dem zweiten Host (zum Glueck) nicht aufgetreten ist UND dass eine komplette Neuinstallation des ersten Host genau das selbe Ergebnis brachte. Waehrend ich das Backup-System aufgebaut habe und die ersten VMs am Verschieben war, konnte ich mich endlich in Ruhe dem Problem widmen und austesten.
Auch dass die lvm.conf auf beiden Servern die selbe (default-)Config aufwies aber nach der beschriebenen Aenderung multipath wieder funktionierte.

Eventuell hat ja wirklich etwas generell im System geaendert (udev? lvm?) und es handelt sich um ein Problem, welchem in Zukunft mehrere Leute begegnen. Die zusaetzliche Config in der lvm.conf:

Code:

# added by pve-manager to avoid scanning ZFS zvols and Ceph rbds
global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|"]

Wird auch ihre Geschichte haben...

Eventuell taucht ja der OP bald mal auf und kann es bei sich testen ob der beschriebene Filter das Problem bei Ihm auch loest.

mpath Fehler "error getting device [EBUSY]" nach 7to8 Update

New Member

Attachments

Distinguished Member

Active Member

Attachments

Distinguished Member

Active Member

Active Member

Distinguished Member

Active Member

Active Member

Active Member

Distinguished Member

Active Member

Distinguished Member

Active Member

Distinguished Member

Active Member

Distinguished Member

Active Member

Distinguished Member

Active Member