PVs appear on duplicate devices

unter Online ▾ Stichwort Storage / Virtualization
GeschÀtzte Lesezeit: 2 Minuten

Nach dem Upgrade eines Stage-Systems von Proxmox 8 auf Proxmox 9 erhielt ich diese interessante Meldung. Und weil die Suchergebnisse dafĂŒr teilweise fragwĂŒrdige LösungsansĂ€tze aufzeigten, möchte ich diesen auch meinen (etwas weniger fragwĂŒrdigen) hinzufĂŒgen.

Die Ausgangslage war eine vergleichsweise simple: zwei Stage-Systeme, nÀmlich pve-example-1 und pve-example-2, die als Proxmox-Cluster agieren und die ich zum Rumspielen benutze. Sie nutzen DRBD, um ihre VMs darauf abzulegen:

  • einmal ein drbd0, das jeweils das /dev/sdc1 der beiden Hosts nutzt und
  • ein drbd1, das jeweils das /dev/sdd1 der beiden Hosts nutzt.

WĂ€hrend pve-example-1 nach wie vor auf Proxmox 8 war, war ich gerade dabei, pve-example-2 auf Proxmox 9 zu bringen. Und bei der Installation der Upgrades maulte der schon herum.

...
Purging configuration files for proxmox-kernel-6.8.12-17-pve-signed (6.8.12-17) ...
Examining /etc/kernel/postrm.d.
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 6.8.12-17-pve /boot/vmlinuz-6.8.12-17-pve
update-initramfs: Deleting /boot/initrd.img-6.8.12-17-pve
run-parts: executing /etc/kernel/postrm.d/proxmox-auto-removal 6.8.12-17-pve /boot/vmlinuz-6.8.12-17-pve
run-parts: executing /etc/kernel/postrm.d/zz-proxmox-boot 6.8.12-17-pve /boot/vmlinuz-6.8.12-17-pve
Re-executing '/etc/kernel/postrm.d/zz-proxmox-boot' in new private mount namespace..
No /etc/kernel/proxmox-boot-uuids found, skipping ESP sync.
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 6.8.12-17-pve /boot/vmlinuz-6.8.12-17-pve
Generating grub configuration file ...
WARNING: Not using device /dev/sdc1 for PV nTxzj2-FyRe-YJST-LZJY-cYrf-QzY8-dFkY2l.
WARNING: Not using device /dev/sdd1 for PV WWWQvj-9a68-iw5b-EbYj-vym9-Zrvd-Yl5zqs.
WARNING: PV nTxzj2-FyRe-YJST-LZJY-cYrf-QzY8-dFkY2l prefers device /dev/drbd0 because device size is correct.
WARNING: PV WWWQvj-9a68-iw5b-EbYj-vym9-Zrvd-Yl5zqs prefers device /dev/drbd1 because device size is correct.
...
WARNING: Not using device /dev/sdc1 for PV nTxzj2-FyRe-YJST-LZJY-cYrf-QzY8-dFkY2l.
WARNING: Not using device /dev/sdd1 for PV WWWQvj-9a68-iw5b-EbYj-vym9-Zrvd-Yl5zqs.
WARNING: PV nTxzj2-FyRe-YJST-LZJY-cYrf-QzY8-dFkY2l prefers device /dev/drbd0 because device size is correct.
WARNING: PV WWWQvj-9a68-iw5b-EbYj-vym9-Zrvd-Yl5zqs prefers device /dev/drbd1 because device size is correct.
...

Ich beließ das vorerst ganz bewusst so und spielte ein bisschen mit dem Setup. Und es zeigte sich: in dem Zustand lassen sich VMs nicht mehr migrieren – bei dem Versuch kam es zu nachfolgender Fehlermeldung:

2026-01-23 13:46:50 starting migration of VM 200 to node 'pve-example-2' (192.168.255.22)
2026-01-23 13:46:50 starting VM 200 on remote node 'pve-example-2'
2026-01-23 13:46:51 [pve-example-2] can't activate LV '/dev/vms-pve-example-2/vm-200-disk-0': Cannot activate LVs in VG vms-pve-example-2 while PVs appear on duplicate devices.
2026-01-23 13:46:51 ERROR: online migrate failure - remote command failed with exit code 255
2026-01-23 13:46:51 aborting phase 2 - cleanup resources
2026-01-23 13:46:51 migrate_cancel
2026-01-23 13:46:52 ERROR: migration finished with problems (duration 00:00:03)
TASK ERROR: migration problems

Nach ein wenig „Jugend forscht“ landete ich beim Kommando pvs, und dessen Ausgabe las sich wie folgt:

WARNING: Not using device /dev/sdc1 for PV nTxzj2-FyRe-YJST-LZJY-cYrf-QzY8-dFkY2l.
WARNING: Not using device /dev/sdd1 for PV WWWQvj-9a68-iw5b-EbYj-vym9-Zrvd-Yl5zqs.
WARNING: PV nTxzj2-FyRe-YJST-LZJY-cYrf-QzY8-dFkY2l prefers device /dev/drbd0 because device size is correct.
WARNING: PV WWWQvj-9a68-iw5b-EbYj-vym9-Zrvd-Yl5zqs prefers device /dev/drbd1 because device size is correct.
PV         VG                Fmt  Attr PSize   PFree
/dev/drbd0 vms-pve-example-1 lvm2 a--  <15.00g  <5.99g
/dev/drbd1 vms-pve-example-2 lvm2 a--  <15.00g <10.00g
/dev/sda3  pve               lvm2 a--   <9.50g      0
/dev/sdb   pvedata           lvm2 a--   <5.00g      0

An der Stelle nun kamen die einschlĂ€gigen Foren und Communities und deren RatschlĂ€ge ins Spiel. Und was ich keinesfalls unterschreiben wĂŒrde ist, dass

  • Ignorieren und schlichtes Negieren Issues wie diese zuverlĂ€ssig fixen (find ich auch eher schwierig, wenn sich ja nichts mehr migrieren lĂ€sst),
  • Reboots Issues wie diese zuverlĂ€ssig fixen,
  • einfach mal fdisk oder parted oder Ähnliches auf /dev/sdc und /dev/sdd und da-eine-Partitionstabelle-reinschreiben-und-dann-passt-das-schon Issues wie diese zuverlĂ€ssig fixen.

Meine etwas weniger invasive Vorgehensweise bestand darin, /etc/lvm/lvm.conf zu editieren und um einen entsprechenden Filter zu erweitern. Das r steht hier fĂŒr reject the path, die folgende Zeile weist also an, /dev/sdc.* und /dev/sdd.* zu ignorieren.

## file: "/etc/lvm/lvm.conf"
# How LVM uses block devices
devices {
  ...
  filter = [ "r|/dev/sdc.*|", "r|/dev/sdd.*|" ]
  ...
}

Auch nach dieser Änderung ist grundsĂ€tzlich kein Reboot nötig – vgscan reicht aus.

Somit ist alles ordentlich, die WARNINGS verschwinden, und auch Migrationen sind nun wieder möglich. Und vielleicht hilft euch das ja auch mal weiter, wer weiß 🙃

Hintergrundbild © Marianne Spiller · Alle Rechte vorbehalten

Hinterlasse einen Kommentar

Ich freue mich ĂŒber jeden Kommentar, es sei denn, er ist blöd.
Deshalb sind die Kommentare auf dieser Seite auch generell moderiert.

(Nick)Name: (erforderlich)
E-Mail: (erforderlich, wird nicht veröffentlicht)
Website: (optional)

Reaktionen aus dem Fediverse

Sofern du selbst einen ActivityPub-Account (wie beispielsweise Mastodon) nutzt, erscheinen auch deine Antworten auf mein Artikel-Announcement automatisch hier.