This update enables the Asymmetric Logical Unit Access (ALUA) feature for the pscsi and tcmu back ends if the kernel supports it. The "targetcli list" command is now able to list ALUA groups.
Tested with:
- kernel-3.10.0-915.el7
- targetcli-2.1.fb46-6.el7
- python-configshell-1.1.fb23-4.el7
- python-rtslib-2.1.fb63-12.el7
The issue is no longer reproducible; No regression found.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHEA-2018:3019
Description of problem: Currently: --------- [root@localhost rtslib-fb]# targetcli /backstores/user:glfs ls o- user:glfs ............................. [Storage Objects: 1] o- block1 [test.124.227/block-store/ee47d739-18b5-497a-8d28-be886894c8af (1.0GiB) activated] o- alua .................................. [ALUA Groups: 0] [root@localhost rtslib-fb]# After: (including patch https://github.com/open-iscsi/rtslib-fb/pull/99) ----- [root@localhost rtslib-fb]# targetcli /backstores/user:glfs ls o- user:glfs ............................. [Storage Objects: 1] o- block1 [test.124.227/block-store/ee47d739-18b5-497a-8d28-be886894c8af (1.0GiB) activated] o- alua .................................. [ALUA Groups: 1] o- default_tg_pt_gp ...... [ALUA state: Active/optimized] [root@localhost rtslib-fb]# This is needed to change the default alua alua_access_type to '0' [root@localhost rtslib-fb]# targetcli /backstores/user:glfs/block1/alua/default_tg_pt_gp get alua alua_access_type alua_access_type=3 [root@localhost rtslib-fb]# targetcli /backstores/user:glfs/block1/alua/default_tg_pt_gp set alua alua_access_type=0 Parameter alua_access_type is now '0'. Need backport of: https://github.com/open-iscsi/rtslib-fb/pull/99/commits/3ff084a7bb44d26b26f6f7e4067b5809741503b1