Home / server / Questions / 812388
In Process
dross
Asked: 2016-11-01 13:16:23 +0800 CST

iSCSI configuration on RHEL 7 with existing volume from old Freenas

  • 772

Recently stopped using FreeNas where I had set up a zfspool with 3 extents which were shared over iscsi.

I am now using these disks in a RHEL 7.2 server and want to reshare the existing zfspool using iscsi (as I had been doing with FreeNas)

I have installed and setup zfs which picked up the existing pool:

[root@sycamore ~]# zpool status
  pool: STORAGE
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
    still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
    the pool may no longer be accessible by software that does not support
    the features. See zpool-features(5) for details.
  scan: none requested
config:

NAME                                          STATE     READ WRITE CKSUM
STORAGE                                       ONLINE       0     0     0
  mirror-0                                    ONLINE       0     0     0
    ata-ST2000DL003-9VT166_5YD2PYT4           ONLINE       0     0     0
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300200707  ONLINE       0     0     0
  mirror-1                                    ONLINE       0     0     0
    ata-ST2000DL003-9VT166_6YD1FVPV           ONLINE       0     0     0
    ata-ST32000542AS_6XW1YDN4                 ONLINE       0     0     0

errors: No known data errors
[root@sycamore ~]# df -h
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/rhel_sycamore-root00  215G  4.0G  211G   2% /
devtmpfs                           24G     0   24G   0% /dev
tmpfs                              24G  1.3M   24G   1% /dev/shm
tmpfs                              24G  9.5M   24G   1% /run
tmpfs                              24G     0   24G   0% /sys/fs/cgroup
/dev/sde1                         247M  208M   39M  85% /boot
/dev/mapper/rhel_sycamore00-home  699G  193M  699G   1% /home
tmpfs                             4.8G   16K  4.8G   1% /run/user/1000
STORAGE                           3.6T  1.6T  2.0T  44% /STORAGE
STORAGE/.samba4                   2.0T  128K  2.0T   1% /STORAGE/.samba4

I have also set up an iscsi target and portal but am not sure how to associate the existing extents to the target:

[root@sycamore STORAGE]# ls -l 
total 1636815334
-rw-r--r--. 1 root root 1650878054400 Oct 18 17:56 extent
-rw-r--r--. 1 root root 1100585369600 Oct 18 19:31 extent2
-rw-r--r--. 1 root root 1100585369600 Oct 18 17:56 extent3
[root@sycamore STORAGE]# pwd
/STORAGE

[root@sycamore ~]# targetcli
targetcli shell version 2.1.fb41
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.

/> ls
o- / ...........................................................,.......[...]
  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.2003-01.org.linux-iscsi.sycamore.x8664:sn.253bc772ce44 . [TPGs: 1]
  |   o- tpg1 ........................................ [no-gen-acls, no-auth]
  |     o- acls ................................................... [ACLs: 0]
  |     o- luns ................................................... [LUNs: 0]
  |     o- portals ............................................. [Portals: 1]
  |       o- 192.168.2.10:3260 ......................................... [OK]
  o- loopback .................................................. [Targets: 0]
/>

How can I complete what I need to do ?

zfs

1 Answers

  1. You've already created an iSCSI target and a portal for it to listen on, which are necessary first steps.

    You need to define backing stores in /backstores/block or /backstores/fileio. These should be the paths to your block devices for files, whichever you're using.

    They can be created like so:

    /backstores/block create name=<name> dev=<path/to/block/device>

    After doing that for all relevant pre-created backing stores, you'll need to map them as LUNS to an ACL that you define within a target. The first step here is to create the LUNs within your target portal group.

    /iscsi/<targetname>/tpg1/luns/ create /backstores/block/<name of backstore>

    Once you have done that for all relevant LUNs for this target, you'll need to make ACLs to that your initiators can connect to your target. This is done by specifying the initiator IQN as your ACL. This will allow discovery and login.

    /iscsi/<targetname>/tpg1/acls/ create <initiator IQN>

    After this is done, map LUNs as need be to their appropriate ACLs. This is automatically done by default, and is appropriate in most scenarios. Using automatic mapping, you would be specifying a target per dedicated storage, and adding ACLs to that target to enable the sharing of LUNs in a cluster or similar. If this is what you want, then you're done. You should be able to connect to your targets.

    However, in a non-shared environment where initiators are all using the same target name (such as a mass deployed iSCSI boot scenario with fixed firmware settings), then manually mapping limited ranges of LUNs for each ACLs within a target becomes useful. To do this, you will have to first disable automatic mapping.

    > set global auto_add_mapped_luns=false

    /iscsi/<targetname>/tpg1/acls/<initiator IQN>/ create <mapped_lun> <tpg lun or explicit backstore>

    In that command, mapped_lun refers to the LUN ID that you'll be seeing within the ACL. It's typical to start from zero for each ACL. You may also define backstores directly (via /backstores/block/<name>) instead of luns pre-mapped in luns/ to avoid having to manually create those mappings yourself (and skip a step).

    • 2