iSCSI Target and Initiator Configuration on RHEL 7

Configure iSCSI target via targetcli on RHEL 7.

Software

Software used in this article:

  1. RedHat Enterprise Linux 7.0
  2. targetcli 2.1.fb34
  3. iscsi-initiator-utils 6.2.0

Before We Begin

We have 3 VMs available, named ipa, srv1 and srv2. The ipa server, which we set up before, will be configured as an iSCSI target, and srv1 and srv2 will be iSCSI clients.

  1. iSCSI target provides remote block storage and is called server,
  2. iSCSI initiator uses this that storage and is called client.

iSCSI Target Installation

On the IPA server, that is going to act as an iSCSI target, create a volume group with a 100MB logical volume to use for iSCSI:

# vgcreate vg_san /dev/sdb
# lvcreate --name lv_block1 --size 100M vg_san

Install targetcli package and enable the target service to start on boot:

# yum install -y targetcli
# systemctl enable target

Configure firewalld to allow incoming iSCSI traffic on a TCP port 3260:

# firewall-cmd --add-port=3260/tcp --permanent
# firewall-cmd --reload

Configure iSCSI Target

Run targetcli to configure iSCSI target:

# targetcli

Our plan for configuring the target is as follows:

  1. backstore –> block,
  2. backstore –> fileio,
  3. iscsi (IQN name),
  4. iscsi –> tpg1 –> portals,
  5. iscsi –> tpg1 –> luns,
  6. iscsi –> tpg1 –> acls.

Create a couple of backstores, block and fileio, with a local file system cache disabled to reduce the risk of data loss:

/> backstores/block create block1 /dev/vg_san/lv_block1 write_back=false
/> backstores/fileio create file1 /root/file1.img size=100M sparse=true write_back=false

Create an IQN (Iscsi Qualified Name).

/> iscsi/ create iqn.2003-01.local.rhce.ipa:target
Created target iqn.2003-01.local.rhce.ipa:target.
Created TPG 1.

On RHEL 7.0 we need to create a portal, however, portal configuration is created automatically on RHEL 7.2.

/> iscsi/iqn.2003-01.local.rhce.ipa:target/tpg1/portals create 0.0.0.0 ip_port=3260

Create a lun for the fileio backstore:

/> iscsi/iqn.2003-01.local.rhce.ipa:target/tpg1/luns create /backstores/fileio/file1

Create two acls for our iSCSI clients (srv1 and srv2), but don’t add the previously mapped lun to the srv1 – the lun should only be available to the srv2:

/> iscsi/iqn.2003-01.local.rhce.ipa:target/tpg1/acls create iqn.1994-05.com.redhat:srv1 add_mapped_luns=false
/> iscsi/iqn.2003-01.local.rhce.ipa:target/tpg1/acls create iqn.1994-05.com.redhat:srv2

Create a lun for the block backstore, this lun will be available for both servers:

/> iscsi/iqn.2003-01.local.rhce.ipa:target/tpg1/luns create /backstores/block/block1

Disable authentication (should be disabled by default anyway):

/> iscsi/iqn.2003-01.local.rhce.ipa:target/tpg1 set attribute authentication=0

Optionally, set a userid and a password. Navigate to a certain acl of our target:

/> iscsi/iqn.2003-01.local.rhce.ipa:target/tpg1/acls/iqn.1994-05.com.redhat:srv1/ set auth userid=client password=client

Save the configuration and exit.

/> saveconfig

List the configuration:

/> ls
o- / ....................................................................................... [...]
  o- backstores ............................................................................ [...]
  | o- block ................................................................ [Storage Objects: 1]
  | | o- block1 .......................... [/dev/vg_san/lv_block1 (100.0MiB) write-thru activated]
  | o- fileio ............................................................... [Storage Objects: 1]
  | | o- file1 ................................. [/root/file1.img (100.0MiB) write-thru activated]
  | o- pscsi ................................................................ [Storage Objects: 0]
  | o- ramdisk .............................................................. [Storage Objects: 0]
  o- iscsi .......................................................................... [Targets: 1]
  | o- iqn.2003-01.local.rhce.ipa:target ............................................... [TPGs: 1]
  |   o- tpg1 ............................................................. [no-gen-acls, no-auth]
  |     o- acls ........................................................................ [ACLs: 2]
  |     | o- iqn.1994-05.com.redhat:srv1 ........................................ [Mapped LUNs: 1]
  |     | | o- mapped_lun0 .............................................. [lun1 block/block1 (rw)]
  |     | o- iqn.1994-05.com.redhat:srv2 ........................................ [Mapped LUNs: 2]
  |     |   o- mapped_lun0 .............................................. [lun0 fileio/file1 (rw)]
  |     |   o- mapped_lun1 .............................................. [lun1 block/block1 (rw)]
  |     o- luns ........................................................................ [LUNs: 2]
  |     | o- lun0 ............................................... [fileio/file1 (/root/file1.img)]
  |     | o- lun1 ......................................... [block/block1 (/dev/vg_san/lv_block1)]
  |     o- portals .................................................................. [Portals: 1]
  |       o- 0.0.0.0:3260 ................................................................... [OK]
  o- loopback ....................................................................... [Targets: 0]

Restart the target and check its status:

# systemctl restart target
# systemctl status target

Configure iSCSI Client (Initiator)

Configuration of an iSCSI initiator requires installation of the iscsi-initiator-utils package, which includes the iscsi and the iscsid services and the /etc/iscsi/iscsid.conf and /etc/iscsi/initiatorname.iscsi configuration files.

On the iSCSI clients srv1 and srv2, install the package:

# yum install -y iscsi-initiator-utils

Note well that on the iSCSI initiator both services are needed. The iscsid service is the main service that accesses all configuration files involved. The iscsi service is the service that establishes the iSCSI connections.

# systemctl enable iscsi iscsid

Our plan for configuring the client is as follows:

  1. Configure iSCSI initiatorname,
  2. Discover targets,
  3. Log into targets.

Open the file /etc/iscsi/initiatorname.iscsi for editing, and the initiator’s name iqn.1994-05.com.redhat:srv1.

If username and password were configured, put them into /etc/iscsi/iscsid.conf:

node.session.auth.authmethod = CHAP
node.session.auth.username = client
node.session.auth.password = client

Be advised that CHAP authentication does not use strong encryption for the passing of credentials. If security of iSCSI data is a requirement, controlling the network side of the protocol is a better method to assure it. For example, using an isolated vlans to pass the iSCSI traffic will be a better implementation from a security point of view.

Discover targets (the ipa server is on 10.8.8.70):

# iscsiadm -m discovery -t sendtargets -p 10.8.8.70:3260
10.8.8.70:3260,1 iqn.2003-01.local.rhce.ipa:target
# iscsiadm -m discovery -P1
SENDTARGETS:
DiscoveryAddress: 10.8.8.70,3260
Target: iqn.2003-01.local.rhce.ipa:target
        Portal: 10.8.8.70:3260,1
                Iface Name: default
iSNS:
No targets found.
STATIC:
No targets found.
FIRMWARE:
No targets found.

Log into the discovered target:

# iscsiadm -m node -T iqn.2003-01.local.rhce.ipa:target -p 10.8.8.70:3260 --login

Check the session:

# iscsiadm -m session -P3 | less

An iSCSI disk should be available at this point. Note that the server srv2 will see both an iSCSI block disk block1 as well as fileio file1, since both are mapped to the server. This will not be the case for the server srv1.

[srv1]# lsblk --scsi|grep LIO
sdb  3:0:0:0    disk LIO-ORG  block1   4.0  iscsi

Create a filesystem:

[srv1]# mkfs.ext4 -m0 /dev/sdb

Create a mount point and get UUID:

[srv1]# mkdir /mnt/block1
[srv1]# blkid | grep sdb
/dev/sdb: UUID="6a1c44d0-3e2f-49fc-85ba-ced3e44bb5b0" TYPE="ext4"

Add the following to /etc/fstab:

UUID=6a1c44d0-3e2f-49fc-85ba-ced3e44bb5b0 /mnt/block1 ext4 _netdev 0 0

Mount the iSCSI drive:

[srv1]# mount /mnt/block1

We can logout or delete the session this way:

# iscsiadm -m node -T iqn.2003-01.local.rhce.ipa:target -p 10.8.8.70:3260 --logout
# iscsiadm -m node -T iqn.2003-01.local.rhce.ipa:target -p 10.8.8.70:3260 -o delete

If things go wrong, we can stop the iscsi.service and remove all files under /var/lib/iscsi/nodes to clean up all current configuration. After doing that, we need to restart the iscsi.service and start the discovery and login again.

66 thoughts on “iSCSI Target and Initiator Configuration on RHEL 7

  1. # systemctl stop target
    # lvextend -L +200M -r /dev/vgsan/lvsan1

    #systemctl start target

    it keeps the old size even after rebooting the server
    remounting it on the initiator ot re-ligging after clearing /var/lib/iscsi/nodes makes the device lost at all (yes, the UUID was updated in /etc/fstab after the re-formatting)

  2. the client takes very long time to unmount the iscsi disks, is it normal? am I supposed to do something about it?
    I am thinking to add a script to stop the iscsi service before shutdown is it the right thing to do for the exam?

    • It takes a second for iSCSI disks to be unmounted in my test lab. Therefore I believe it should not take much time.

      In terms of scripting, I’d only write one if there is an exam task to do so.

  3. Hi Tomas,

    I ran this command, my screen appeared this error, should i remove “write_back=false” ?
    /> backstores/block create block1 /dev/vg_san/lv_block1 write_back=false
    Unexpected keyword parameter ‘write_back’.

    • Hi Tomas,

      I couldn’t log into discovered target on srv2. But on srv1, i logged into discovered target successful. When i tried to log into discovered target, i show error

      [[email protected] ~]# iscsiadm -m node -T iqn.2003-01.local.rhce.ipa:target -p 10.0.0.130:3260 –login
      Logging in to [iface: default, target: iqn.2003-01.local.rhce.ipa:target, portal: 10.0.0.130,3260] (multiple)
      iscsiadm: Could not login to [iface: default, target: iqn.2003-01.local.rhce.ipa:target, portal: 10.0.0.130,3260].
      iscsiadm: initiator reported error (24 – iSCSI login failed due to authorization failure)
      iscsiadm: Could not log into all portals
      [[email protected] ~]# iscsiadm -m session -P3 | less
      iscsiadm: No active sessions.

      Can i log into discovered target on srv2 ?, if yes, show me the way

      Thanks and Regard !

    • Looks like an authentication issue to me. Ensure that the iSCSI target is configured to allow srv2 to log in, verify iSCSI initiator name, make sure it matches.

    • Check what options are available for block creation on the system that you use, if there is no write_back, then remove it.

    • Any chance you had a different initiator name on the srv2 that tried to access the target? It may be cached, try clearing it.

      You should be able to create it, yes, assuming the iSCSI target is configured and working properly.

    • Oh God, i made it work properly. My last question in this post is ” When i ran commands mkfs.ext4 -m0 /dev/sdb -> mkdir /mnt/block1 -> … -> mount /mnt/block1 in srv1, /mnt/block1 mounted that just can be seen in srv1, srv2 is not, why ?????. By definition, iSCSI is a shared storage ”

      Thank you so much for this topic
      Have a nice day !

    • This is problem :(

      [[email protected] ~]# mkdir /mnt/block1
      [[email protected] ~]# blkid | grep sdb
      /dev/sdb: UUID=”fa121996-eb2e-4f56-a0a1-91c97e4cef0f” TYPE=”ext4″
      [[email protected] ~]# vi /etc/fstab
      [[email protected] ~]# mount /mnt/block1
      [[email protected] ~]# df -h
      Filesystem Size Used Avail Use% Mounted on
      /dev/mapper/cl-root 17G 1.8G 16G 11% /
      devtmpfs 902M 0 902M 0% /dev
      tmpfs 912M 0 912M 0% /dev/shm
      tmpfs 912M 8.7M 904M 1% /run
      tmpfs 912M 0 912M 0% /sys/fs/cgroup
      /dev/sda1 1014M 167M 848M 17% /boot
      tmpfs 183M 0 183M 0% /run/user/0
      /dev/sdb 35G 49M 35G 1% /mnt/block1
      [[email protected] ~]# cat /proc/partitions
      major minor #blocks name

      8 0 20971520 sda
      8 1 1048576 sda1
      8 2 19921920 sda2
      11 0 1048575 sr0
      253 0 17821696 dm-0
      253 1 2097152 dm-1
      8 16 36700160 sdb

      [[email protected] ~]# lsblk –scsi|grep LIO
      sdb 3:0:0:0 disk LIO-ORG file1 4.0 iscsi
      sdc 3:0:0:1 disk LIO-ORG block1 4.0 iscsi
      [[email protected] ~]# df -h
      Filesystem Size Used Avail Use% Mounted on
      /dev/mapper/cl-root 17G 1.8G 16G 11% /
      devtmpfs 902M 0 902M 0% /dev
      tmpfs 912M 0 912M 0% /dev/shm
      tmpfs 912M 8.6M 904M 1% /run
      tmpfs 912M 0 912M 0% /sys/fs/cgroup
      /dev/sda1 1014M 167M 848M 17% /boot
      tmpfs 183M 0 183M 0% /run/user/0
      [[email protected] ~]# cat /proc/partitions
      major minor #blocks name

      8 0 20971520 sda
      8 1 1048576 sda1
      8 2 19921920 sda2
      11 0 1048575 sr0
      253 0 17821696 dm-0
      253 1 2097152 dm-1
      8 16 36700160 sdb
      8 32 36700160 sdc

      Why mount point /dev/sdb can be seen from linux1, but can’t be seen in linux2 ?. I ran comman “cat /proc/partitions”, i still see sdb disk from both nodes

    • As per my previous reply, the backstore file1 is mapped to one server only. Go to the target, map the lun to both servers (srv1 and srv2), and you will be able to see /dev/sdb on both clients, and both clients will be able to mount it. I tested it, and all worked fine.

    • [[email protected] block1]# df -h
      Filesystem Size Used Avail Use% Mounted on
      /dev/mapper/cl-root 17G 1.7G 16G 10% /
      devtmpfs 902M 0 902M 0% /dev
      tmpfs 912M 0 912M 0% /dev/shm
      tmpfs 912M 8.6M 904M 1% /run
      tmpfs 912M 0 912M 0% /sys/fs/cgroup
      /dev/sda1 1014M 184M 831M 19% /boot
      tmpfs 183M 0 183M 0% /run/user/0
      /dev/sdb 35G 49M 35G 1% /mnt/block1

      [[email protected] block1]# df -h
      Filesystem Size Used Avail Use% Mounted on
      /dev/mapper/cl-root 17G 1.7G 16G 10% /
      devtmpfs 902M 0 902M 0% /dev
      tmpfs 912M 0 912M 0% /dev/shm
      tmpfs 912M 8.7M 904M 1% /run
      tmpfs 912M 0 912M 0% /sys/fs/cgroup
      /dev/sda1 1014M 184M 831M 19% /boot
      tmpfs 183M 0 183M 0% /run/user/0
      /dev/sdb 35G 326M 34G 1% /mnt/block1

      I can mount /dev/sdb, but size /dev/sdb on srv1 different than srv2, they’re not same. Why ???, i thought they use that /dev/sdb together ??, used size of /dev/sdb must be similar on both of nodes ???

    • They aren’t the same (well, they should be the same when you mount them initially) because you formatted /dev/sdb as an ext4. As soon as you make changes to the disk /dev/sdb on the server srv1, another server srv2 has no awareness of that and you will eventually lose data, if you make changes from the server srv2.

      Ext4 is not a shared-disk filesystem. Use GFS2 if you want to have both servers writing to the same iSCSI disk.

    • Hi Alex, this parameter creates a thin provisioned LUN. Thin provisioning is called “sparse volumes” sometimes.

      The idea here is to allocate blocks of data on-demand rather than allocating all the blocks in advance.

  4. Yesterday in RHCE exam i forgot to logout the iscsiadm and before checking by reboot my time was over and system automatically poweroff so iscsiadm login will create any problem or i will pass or fail ? Plz help me frnds i m very nervous

    • You are right,
      You do not need to enable iscsid, this service you will touch (restart) just if you change the iqn in the initiator config file.

  5. Hi Tomas,

    Great guide, but apparently, CentOS7/RHEL7 has made some pretty big chances when it comes to LVM filtering of PVs/VGs, which can cause some issues when trying to do a reboot on the target.

    You can basically recreate this issue on a CentOS7/RHEL7 machine. Go through the process as normal, then reboot the target (It should be noted, that I properly unmounted all drives from the initiator correctly, and was able to reboot the client/initatior multiple times and was able to mount everything from fstab. It’s only when the target gets rebooted is when everything gets weird) :

    You’ll go from this:

    o- iscsi …………………………………………………. [Targets: 1]
    o- iqn.2017-05.com.mylabserver:t1 ……………………………. [TPGs: 1]
    o- tpg1 ……………………………………… [no-gen-acls, no-auth]
    o- acls ……………………………………………….. [ACLs: 1]
    | o- iqn.2017-05.com.mylabserver:client …………….. [Mapped LUNs: 1]
    | o- mapped_lun0 ………………………….. [lun0 block/test (rw)]
    o- luns ……………………………………………….. [LUNs: 1]
    | o- lun0 ………………………………… [block/test (/dev/xvdg)]
    o- portals ………………………………………….. [Portals: 1]
    o- 0.0.0.0:3260 …………………………………………… [OK]

    To, after a reboot, this:

    o- backstores ……………………………………………………………………………………………….. […]
    | o- block …………………………………………………………………………………….. [Storage Objects: 0]
    | o- fileio ……………………………………………………………………………………. [Storage Objects: 0]
    | o- pscsi …………………………………………………………………………………….. [Storage Objects: 0]
    | o- ramdisk …………………………………………………………………………………… [Storage Objects: 0]
    o- iscsi ……………………………………………………………………………………………… [Targets: 1]
    | o- iqn.2017-05.com.mylabserver:t1 ………………………………………………………………………… [TPGs: 1]
    | o- tpg1 ………………………………………………………………………………….. [no-gen-acls, no-auth]
    | o- acls ……………………………………………………………………………………………. [ACLs: 1]
    | | o- iqn.2017-05.com.mylabserver:client …………………………………………………………. [Mapped LUNs: 0]
    | o- luns ……………………………………………………………………………………………. [LUNs: 0]
    | o- portals ………………………………………………………………………………………. [Portals: 1]
    | o- 0.0.0.0:3260 ……………………………………………………………………………………….. [OK]
    o- loopback …………………………………………………………………………………………… [Targets: 0]

    Doing a quick systemctl check shows:

    [[email protected]]# systemctl status target -l
    ● target.service – Restore LIO kernel target configuration
    Loaded: loaded (/usr/lib/systemd/system/target.service; enabled; vendor preset: disabled)
    Active: active (exited) since Wed 2017-05-03 23:06:05 EDT; 47min ago
    Process: 900 ExecStart=/usr/bin/targetctl restore (code=exited, status=0/SUCCESS)
    Main PID: 900 (code=exited, status=0/SUCCESS)
    CGroup: /system.slice/target.service

    May 03 23:06:05 isci-target systemd[1]: Starting Restore LIO kernel target configuration…
    May 03 23:06:05 isci-target target[900]: Could not create StorageObject test: Cannot configure StorageObject because device /dev/xvdg is already in use, skipped
    May 03 23:06:05 isci-target target[900]: Could not find matching StorageObject for LUN 0, skipped
    May 03 23:06:05 isci-target target[900]: Could not find matching TPG LUN 0 for MappedLUN 0, skipped

    The LUNs, backstores, EVERYTHING related to the drives is gone from the configuration. Any changes that the client made before the reboot (e.g. If he/she made LVMs, partitions, swaps, etc) will be available on the target; however, unreachable by the initiator (As the client, I see no drives being served from the ISCSI target — only what’s locally available to the initiator/client system).

    Here’s some others with this issue, but no one really has a solution: https://serverfault.com/questions/837827/centos7-targetcli-configuration-lost-after-server-reboot

    There’s a comment on CertDepot’s ISCSI guide about LVM filtering (https://www.certdepot.net/rhel7-configure-iscsi-target-initiator-persistently/#comment-41214), but my own Googling only came up with this man page

    https://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/lvm_filters.html

    I’ll see if I have to do this BEFORE the reboot; however, trying this afterwards, hasn’t really helped.

    This has me worried, especially for the test. If the person grading the test does a reboot, then essentially I would fail this section because he/she would see no drives from the initiator perspective.

    Any thoughts?

    • Thanks for all the details, much appreciated! Unfortunately I cannot advise much I’m afraid as I never encountered this problem. Which dot version of RHEL 7 do you have the issue on?

      LVM filtering does look like a sensible approach, I tend to exclude /dev/cdrom by default.

  6. Hi, great tutorial. My devices are not mounted on boot. After boot, I have to manually execute the iscsiadm ……. –login and then mount -all for them to mount. The services iscsi and iscsid are set to mount at boot. Any ideas as to why this is happening?

    • Anything in the system log after a boot? If the services tried to mount devices, there should be logs available to help you troubleshoot.

  7. Hello, everyone.
    Is it normal if I start initiator before target the iscsi failed and I have to restart iscsi service after target is loaded?? Or is it abnormal situation and iscsi should automatically see that target and mount remote disk?
    Thanks.

  8. We have 3 servers
    server1 ( main server )
    server2 ( client )
    server3 ( client )

    How do I allow target should only be allowed to server2 not on server3.

    • You can use ACLs for your iSCSI clients, or you can use firewall rules.

      The blog post contains an example of using ACLs.

  9. By the way don’t forget to add in fstab the ‘_netdev’ option, otherwise you may not boot.

  10. Does creation order matters,
    I have followed this scheme

    iscsi –> tpg1 –> acls.
    iscsi –> tpg1 –> luns,
    iscsi –> tpg1 –> portals,
    with this scheme first i created acl.
    /> iscsi/iqn.2003-01.local.rhce.ipa:target/tpg1/acls create iqn.1994-05.com.redhat:srv1 add_mapped_luns=false
    /> iscsi/iqn.2003-01.local.rhce.ipa:target/tpg1/acls create iqn.1994-05.com.redhat:srv2

    both the luns are mapped to both acls once they are created.
    and it does not seem to restrict on one server as written by this post.

    also:
    Does naming convention matter ??
    iqn.1994-05.com.redhat:srv2
    com.redhat:srv2 this has to match with the client/server name ???
    or it can be any arbitrary name following convention
    e.g.
    iqn.1994-05.test.example:testserver
    note: example.test does not exist

    • Instructions written in the article do work for the software versions mentioned at the top of the post, and as can be seen from the output of the iscsi configuration, ACL for iqn.1994-05.com.redhat:srv1 has one LUN mapped where iqn.1994-05.com.redhat:srv2 has two LUNs.

      With regards to naming convention, when you create an ACL, you must provide the initiator name of your client (whatever you defined in the file /etc/iscsi/initiatorname.iscsi). You don’t have to use com.redhat and can use test.example if you like.

  11. This is for information purpose only.

    I have configured iscsi on targetcli-2.1.fb46-1.el7.noarch .
    with this version , If I follow this method.
    iscsi –> tpg1 –> acls.
    iscsi –> tpg1 –> luns,
    iscsi –> tpg1 –> portals,
    It does not work well.

    But this sequence works fine.

    iscsi –> tpg1 –> portals,
    iscsi –> tpg1 –> luns,
    iscsi –> tpg1 –> acls.

    • The default behaviour is to automatically add existing LUNs to new ACLs, and new LUNs to existing ACLs. You can use auto_add_mapped_luns to change this.

  12. Is there any way with in targetcli to restrict access to certain acl to certain host.
    acl1 should not be accessible by host1.
    acl2 should only be acessible by host2

    or we need to use firewalld for restriction.

    Thanks

    • There is, you do that by specifying a client when creating an ACL, e.g.:

      acls> create iqn.1994-05.com.redhat:srv2
  13. this is what i asked earlier :)

    “”
    Does naming convention matter ??
    iqn.1994-05.com.redhat:srv2
    com.redhat:srv2 this has to match with the client/server name ???
    or it can be any arbitrary name following convention
    e.g.
    iqn.1994-05.test.example:testserver
    note: example.test does not exist “””

    so to summarize.
    if i use
    acls> create iqn.1994-05.com.redhat:srv2

    this target will be accsible to srv2.redhat.com ,,, right ??

    • Yes, and I answered that you can use any name, and not just com.redhat. The key thing is to use the client’s initiator name when creating an ACLs. As long as you do that, you can use any name. The target will be accessible to the client that has the initiator name of iqn.1994-05.com.redhat:srv2. You however still need to export some LUNs as otherwise the client won’t be able to use any. Having said that, you can create multiple ACLs to control resources each client (initiator) has access to.

  14. system1: system1.mydomain.com
    system2: system2.mydomain.com

    I created this target on system1.mydomain.com and client is system2.mydomain.com.
    ideally iqn.2015-12.com.mydomain.district10:acl1 should not have access on system2, but i am able to access it.

    can you please guide what wrong with my configuration.

    I am trying to create a target that should only be accessible on system2.

    /> ls
    o- / ....................................................................................................................... [...]
      o- backstores ............................................................................................................ [...]
      | o- block ................................................................................................ [Storage Objects: 0]
      | o- fileio ............................................................................................... [Storage Objects: 1]
      | | o- file1 ..................................................................... [/root/file1 (100.0MiB) write-back activated]
      | |   o- alua ................................................................................................. [ALUA Groups: 1]
      | |     o- default_tg_pt_gp ..................................................................... [ALUA state: Active/optimized]
      | o- pscsi ................................................................................................ [Storage Objects: 0]
      | o- ramdisk .............................................................................................. [Storage Objects: 0]
      o- iscsi .......................................................................................................... [Targets: 1]
      | o- iqn.2015-12.com.mydomain.district10:system1 ..................................................................... [TPGs: 1]
      |   o- tpg1 ............................................................................................. [no-gen-acls, no-auth]
      |     o- acls ........................................................................................................ [ACLs: 2]
      |     | o- iqn.2015-12.com.mydomain.district10:acl1 ........................................................... [Mapped LUNs: 1]
      |     | | o- mapped_lun0 .............................................................................. [lun0 fileio/file1 (rw)]
      |     | o- iqn.2015-12.com.mydomain:system2 ................................................................... [Mapped LUNs: 1]
      |     |   o- mapped_lun0 .............................................................................. [lun0 fileio/file1 (rw)]
      |     o- luns ........................................................................................................ [LUNs: 1]
      |     | o- lun0 ................................................................ [fileio/file1 (/root/file1) (default_tg_pt_gp)]
      |     o- portals .................................................................................................. [Portals: 1]
      |       o- 0.0.0.0:3260 ................................................................................................... [OK]
      o- loopback ....................................................................................................... [Targets: 0]
    />
    • I’m looking at the configuration that you’ve posted, and it shows that both initiators iqn.2015-12.com.mydomain.district10:acl1 and iqn.2015-12.com.mydomain:system2 have access to the same LUN.

      What do you want to achieve here? You said that “ideally iqn.2015-12.com.mydomain.district10:acl1 should not have access on system2, but i am able to access it”, which is confusing since both are clients and neither is the target.

      If you want to create a target that should only be accessible by system2, then simply remove access for iqn.2015-12.com.mydomain.district10:acl1.

  15. this does not work for me . I cant guess the problem so far.

    Server:

    /> ls
    o- / .................................................................... [...]
      o- backstores ......................................................... [...]
      | o- block ............................................. [Storage Objects: 0]
      | o- fileio ............................................ [Storage Objects: 1]
      | | o- file1 .................. [/root/file1 (100.0MiB) write-back activated]
      | |   o- alua .............................................. [ALUA Groups: 1]
      | |     o- default_tg_pt_gp .................. [ALUA state: Active/optimized]
      | o- pscsi ............................................. [Storage Objects: 0]
      | o- ramdisk ........................................... [Storage Objects: 0]
      o- iscsi ....................................................... [Targets: 1]
      | o- iqn.2015-12.com.mydomain.district10:system1 .................. [TPGs: 1]
      |   o- tpg1 .......................................... [no-gen-acls, no-auth]
      |     o- acls ..................................................... [ACLs: 1]
      |     | o- iqn.2015-12.com.mydomain:system2 ................ [Mapped LUNs: 1]
      |     |   o- mapped_lun0 ........................... [lun0 fileio/file1 (rw)]
      |     o- luns ..................................................... [LUNs: 1]
      |     | o- lun0 ............. [fileio/file1 (/root/file1) (default_tg_pt_gp)]
      |     o- portals ............................................... [Portals: 1]
      |       o- 0.0.0.0:3260 ................................................ [OK]
      o- loopback .................................................... [Targets: 0]

    Client other than system2: { this system should not have acces to this target }

    [[email protected] ~]# iscsiadm --mode discoverydb --type sendtargets --portal 192.168.1.220 --discover
    192.168.1.220:3260,1 iqn.2015-12.com.mydomain.district10:system1
    [[email protected] ~]# iscsiadm --mode node --targetname iqn.2015-12.com.mydomain.district10:system1 --portal 192.168.1.220:3260 --login
    Logging in to [iface: default, target: iqn.2015-12.com.mydomain.district10:system1, portal: 192.168.1.220,3260] (multiple)
    Login to [iface: default, target: iqn.2015-12.com.mydomain.district10:system1, portal: 192.168.1.220,3260] successful.

    This target ” iqn.2015-12.com.mydomain.district10:system1 “” Should only be allowed on system2 ???

    • Can the client1 see any LUNs? It does not have an ACL created therefore no LUNs should be available to the client1.

  16. so what changes will be required to achieve this task
    This target ” iqn.2015-12.com.mydomain.district10:system1 “” Should only be allowed on system2 ???

    • When you create an ACL on the target, add the initiator name of the client you want to allow access from (in your case system2), and make sure that the client has the initiator name which you configured on the target ACL, as otherwise it won’t work.

  17. Hi Tomas,
    I would really Appreciate if you share your phone number? I really would like to talk with you regarding teaming and IPv6 which crashed my whole networking and failed RHCE last week . I’m scared to rebook the test even though I know almost all contents.

    Thanks!!

    • Hi Santosh, feel free to post any questions/issues that you have on topic-related articles so that other people can also benefit.

  18. Hi Tomas,

    Do you have an experience with iscsi-initiator issue after server(initiator) reboot and after no more iscsi partition(lvm) … no errors — nothing just gone :) … and even when you trying –login again it says successful but no partitions from the iscsi server.

    here is the all info:

    [[email protected] ~]# iscsiadm -m node -T iqn.2017-12.com.example:disk1 -p 50.0.0.60:3260 –login
    Logging in to [iface: default, target: iqn.2017-12.com.example:disk1, portal: 50.0.0.60,3260] (multiple)
    Login to [iface: default, target: iqn.2017-12.com.example:disk1, portal: 50.0.0.60,3260] successful.

    [[email protected] ~]# iscsiadm -m session -P 0
    tcp: [3] 50.0.0.60:3260,1 iqn.2017-12.com.example:disk1 (non-flash)

    [[email protected] ~]# iscsiadm -m session -P 1
    Target: iqn.2017-12.com.example:disk1 (non-flash)
    Current Portal: 50.0.0.60:3260,1
    Persistent Portal: 50.0.0.60:3260,1
    **********
    Interface:
    **********
    Iface Name: default
    Iface Transport: tcp
    Iface Initiatorname: iqn.1994-05.com.redhat:2f1c2ee011be
    Iface IPaddress: 50.0.0.61
    Iface HWaddress:
    Iface Netdev:
    SID: 3
    iSCSI Connection State: LOGGED IN
    iSCSI Session State: LOGGED_IN
    Internal iscsid Session State: NO CHANGE
    [[email protected] ~]#

    FSTAB output

    # Accessible filesystems, by reference, are maintained under ‘/dev/disk’
    # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
    #
    UUID=a78bb152-e525-4f0e-961a-bf6147ac7d3e / xfs defaults 1 1
    /dev/mapper/iscsi-iscsilv /san ext4 _netdev 0 0

    [[email protected] ~]# mount -a
    mount: special device /dev/mapper/iscsi-iscsilv does not exist

    [[email protected] ~]# lsblk
    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    vda 252:0 0 40G 0 disk
    └─vda1 252:1 0 40G 0 part /

    any idea?

    Thanks in advance

    • I didn’t encounter this problem I’m afraid.

      It would help if you posted the iSCSI target configuration from server1 as well as the content of the file /etc/iscsi/initiatorname.iscsi from server2.

    • I’m having exactly same issue on my client server after reboot.But my scenario is little different here.mount -a command doesn’t complain and successfully mounted. I can see the df -h is showing correct mount point.After seeing the correct mount point.I logged out the session and rebooted the client server then rebooted server then I run the command df -h which shows disk is not mounted.I’m wondering,I can go on that directory and create the file.Is this expected on exam?Please see the below and suggest me. Other things went smooth except this issue.
      df -h
      mount /mnt/iscsi
      mount:special device /dev/sdd1 does not exit
      cd /mnt/iscsi
      [[email protected] iscsi]# touch yoyo
      [[email protected] iscsi]# ls
      yoyo

    • In your case, check if sdd1 is reported in /proc/mounts. If it isn’t, then you’re writing to a local folder and not the mountpoint.

  19. I made the silly mistake on fstab. /proc/mounts doesn’t show any /dev/sdd1 .I saw only /dev/sdc1 at the end and I mounted it under /mnt/iscsi then rebooted and Waited for luck…….and… and…..it was there…..Thanks million!!!

  20. One of the good hacks at the beginning of the exam is to do ls /usr/lib/systemd/system > ~/diff1 and after installing some packages that will bring the services as well execute /usr/lib/systemd/system > ~/diff2 ; after that we can do diff diff1 diff2 and see what is installed, this way we do not have to memorize all service names :) cheers

    • Thanks, this is helpful. Although if you’re setting up an iscsi target, it’s not difficult to remember services “iscsi”, “iscsid” and “target”.

  21. Hi Tomas,

    How are you, hope you are god and doing fine , i need some assistance i configured Target Server with following configuration.

    /> ls
    o- / ......................................................................................................................... [...]
      o- backstores .............................................................................................................. [...]
      | o- block .................................................................................................. [Storage Objects: 2]
      | | o- block1 ........................................................................... [/dev/sdb (1.0GiB) write-thru activated]
      | | | o- alua ................................................................................................... [ALUA Groups: 1]
      | | |   o- default_tg_pt_gp ....................................................................... [ALUA state: Active/optimized]
      | | o- block2 ........................................................................... [/dev/sdc (1.0GiB) write-thru activated]
      | |   o- alua ................................................................................................... [ALUA Groups: 1]
      | |     o- default_tg_pt_gp ....................................................................... [ALUA state: Active/optimized]
      | o- fileio ................................................................................................. [Storage Objects: 0]
      | o- pscsi .................................................................................................. [Storage Objects: 0]
      | o- ramdisk ................................................................................................ [Storage Objects: 0]
      o- iscsi ............................................................................................................ [Targets: 1]
      | o- iqn.2019-08.local.rhce.ipa ........................................................................................ [TPGs: 1]
      |   o- tpg1 ............................................................................................... [no-gen-acls, no-auth]
      |     o- acls .......................................................................................................... [ACLs: 2]
      |     | o- iqn.2019-08.local.rhce.serv1 ......................................................................... [Mapped LUNs: 1]
      |     | | o- mapped_lun0 ................................................................................ [lun0 block/block1 (rw)]
      |     | o- iqn.2019-08.local.rhce.serv2 ......................................................................... [Mapped LUNs: 1]
      |     |   o- mapped_lun1 ................................................................................ [lun1 block/block2 (rw)]
      |     o- luns .......................................................................................................... [LUNs: 2]
      |     | o- lun0 ..................................................................... [block/block1 (/dev/sdb) (default_tg_pt_gp)]
      |     | o- lun1 ..................................................................... [block/block2 (/dev/sdc) (default_tg_pt_gp)]
      |     o- portals .................................................................................................... [Portals: 1]
      |       o- 10.8.8.2:3260 .................................................................................................... [OK]
      o- loopback ......................................................................................................... [Targets: 0]

    and when from client initiators discovered and logged in successfully and added the entries in fstab
    ” /dev/sdb1 /mnt xfs rw,seclabel,relatime,attr2,inode64,noquota,_netdev 0 0 ” and then to check persistence i restarted the clients serv1 and serv2. Both got hang with following message

    https://imgur.com/3Q8ZvTI

    and have to manually restart the server and on reboot the initiator doesn’t automatically login hence device also doesn’t mount.

    Target is running on Centos 7.2 and Clients are running on Centos 7.0

Leave a Reply

Your email address will not be published. Required fields are marked *