LVM-filter=r kaputt: automatisches rekursives Oeffnen

[Cae]

Hallo zusammen,

hier lief bis vor ein paar Stunden ein Virtualisierungsserver mit libvirt/qemu und iSCSI-Storage (open-iscsi) und der Storageserver dazu (rtslib-targetcli). Exportiert wird ein einzelnes LUN, welches pro VM ein LVM-LV (iscsi/vm0, iscsi/vm1, ...) enthaelt. Auf dem Storageserver liegt es selbst in einem LV (data/iscsi), welches in der lvm.conf per

Code: Alles auswählen

filter = [ "r|/dev/data/iscsi|" ]

ignoriert wird, damit es auf dem NAS nicht geoeffnet wird.

Genau das tut nicht mehr, moeglicherweise seit dem kuerzlich eingespielten Pointrelease. Das NAS oeffnet bei einem vgchange -ay data automatisch auch data/iscsi mit allen enthaltenen iscsi/vm*-LVs. Als Folge weigert sich targetcli, das Volume zu exportieren:

Code: Alles auswählen

Cannot configure StorageObject because device /dev/data/iscsi is already in use

Die offensichtlichste Loesung, vgchange -an iscsi funktioniert beim Schreiben dieses Posts offenbar doch (vorhin gab es imho "is in use"-Fehler). Damit laesst sich das Target auch wieder definieren und der Mist laeuft wieder. Tippe auf "zwei Uhr Nachts"-Bug.

Damit bleiben aber ein paar Punkte, die verwirren:

1. Volumes werden aufgemacht, obwohl sie ignoriert sind (filter=)
2. lvs merkt, dass ein Filter aktiv ist (" WARNING: Device for PV ... not found or rejected by a filter."), zeigt die zugehoerigen LVs aber trotzdem an.
3. vgchange -ay data hat frueher nicht rekursiv auch Subvolumes aufgemacht.

Ich bin ein bisschen ratlos und hab' auch keine rechte Idee, wo man da ueberhaupt debuggt. Ist das udev? systemd? (jaja, kein Rant, aber ich hatte davor noch Bootprobleme, die sich durch Festnageln auf init=/lib/systemd/systemd geloest hatten) Irgendwas lvmetad-maessiges?