Bug 1170242 - Base OS activates VGs created by clients on iSCSI targets at boot
Base OS activates VGs created by clients on iSCSI targets at boot
Status: CONFIRMED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: YaST2
Leap 15.1
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: YaST Team
Jiri Srain
https://trello.com/c/zLafCyUB
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-04-22 16:01 UTC by Christopher Dick
Modified: 2020-06-21 18:26 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Dick 2020-04-22 16:01:30 UTC
After configuring an unformatted and unmounted partition as an iscsi target using yast2-iscsi-lio-server, any client-created VGs on the device are activated by the server OS at boot, causing the device to be unable to function as a target after a reboot.  The device is now "in use" and unavailable to the iscsi target service.
Comment 1 Arvin Schnell 2020-04-22 18:25:59 UTC
I suppose that it is required to either disable LVM completely or to add
filter rules in lvm.conf so that LVM does not use the disks exported by
iSCSI.
Comment 2 Christopher Dick 2020-04-22 18:37:09 UTC
(In reply to Arvin Schnell from comment #1)
> I suppose that it is required to either disable LVM completely or to add
> filter rules in lvm.conf so that LVM does not use the disks exported by
> iSCSI.

Unfortunately, the only information I've found as a solution to this is a years-old thread talking about filter rules.

I would still qualify it as a "bug" or flaw in the system if the base OS is able to arbitrarily "steal" the VGs from a disk that had been set as an iscsi target.  Perhaps there's a way for yast2-iscsi-lio-server to add a broad filter rule to init or something to ignore anything on devices used as iscsi targets.
Comment 3 Christopher Dick 2020-04-25 02:43:14 UTC
(In reply to Arvin Schnell from comment #1)
> I suppose that it is required to either disable LVM completely or to add
> filter rules in lvm.conf so that LVM does not use the disks exported by
> iSCSI.

After a reboot, executing "vgchange -an [VG name]" allows the the device to be re-added as a target. I'll assume doing a  "vgexport" would allow the client to reimport it's VGs, if performed before making the device a target again.
Comment 4 José Iván López González 2020-06-09 14:37:59 UTC
Maybe YaST could add lvm filters to disable LVM activation over iscsi target devices. And similarly, the lvm filters should be removed when the device is not used as iscsi target anymore.

But I see some problems: what happens with the device when the iscsi service is stopped? What happens when the user manually removes the iscsi target?

Maybe it would be the user's responsibility to add the lvm filter if he/she expects that the iscsi target can be used for LVM.

I think this should be evaluated for our PO.
Comment 5 Arvin Schnell 2020-06-09 14:46:37 UTC
Likely better than filters is using the auto_activation_volume_list or
volume_list parameter in lvm.conf. Maybe in combination with tags.
Comment 6 Ancor Gonzalez Sosa 2020-06-10 08:54:25 UTC
(In reply to José Iván López González from comment #4)
> 
> Maybe it would be the user's responsibility to add the lvm filter if he/she
> expects that the iscsi target can be used for LVM.

Well, I agree we should not do it behind users' back. But expecting the user to know that kind of details defeats the purpose of using YaST.

In my opinion, yast2-iscsi-lio-server should indeed offer the possibility of preventing "LVM stealing" (via filters, tags, or any other mechanisms) with a single click as part of the process of configuring a new target. The user can then take an informed decision about doing it or skipping the step.

Similarly, when removing a target we may try to detect if the filter/tag/whatever is there and, at least, alert the user.

So please create a Trello card to prioritize this and link it to the one we have about iSCSI modules.
Comment 7 Christopher Dick 2020-06-21 18:26:06 UTC
Will a fix for this end up in Leap 15.2 or be released for 15.1?  Is there a way for me to track progress on this bug?