targetcli-fb-devel

targetcli-fb-devel@lists.fedorahosted.org

111 discussions

New releases: targetcli.fb43, rtslib.fb60, configshell.fb20
by Andy Grover 12 Feb '18

12 Feb '18

Hi all, Another release of all three, with a few small improvements to targetcli but nothing major. The big thing is rtslib now uses pyudev instead of parsing /sys itself, which has been a constant source of bugs for us. NOTE: *** rtslib-fb now depends on python-udev *** My future development plans are mainly better support for configuring PR/ALUA. If there's some other issue or annoyance that's bugging you please let me know and we can work to get it improved. Thanks again to everyone who helped make this release! Github: https://github.com/agrover/targetcli-fb https://github.com/agrover/rtslib-fb https://github.com/agrover/configshell-fb tarballs: https://fedorahosted.org/released/targetcli-fb/ targetcli-fb 2.1.fb41: Andy Grover <agrover(a)redhat.com> (5): fileio completions also allow block devices Update man page a little HeaderDigest param should be string, not yesno Allow WWN to be specified when creating storage objects version 2.1.fb43 Andy Grover <andy(a)groveronline.com> (2): Update README.md type in README.md. Christophe Vu-Brugier <cvubrugier(a)fastmail.fm> (2): Document the tpg_enabled_sendtargets TPG attribute Document the unmap_zeroes_data backstore attribute runsisi <runsisi(a)hust.edu.cn> (1): Fix package name for rpm spec file rtslib-fb 2.1.fb60: Andy Grover <agrover(a)redhat.com> (2): Fix 'make rpm' version 2.1.fb60 Andy Grover <andy(a)groveronline.com> (2): Update README.md Update README.md again Fam Zheng <famz(a)redhat.com> (1): UserBackedStorageObject: Fix docstring for __init__ Jon Magrini <jmagrini(a)redhat.com> (1): [rtslib-fb] Ensure internal buffers are flushed when saveconfig.json is written to disk. mulhern <amulhern(a)redhat.com> (3): Make use of pyudev package as much as possible in utils module. Use find_parent instead of parent. Make sure to properly avoid treating partitions the same as disk. configshell-fb 1.1.fb20: Andy Grover <agrover(a)redhat.com> (1): version 1.1.fb20 Christoph Hellwig <hch(a)lst.de> (1): configshell-fb: depend on python-six/python3-six in debian/control Regards -- Andy

2 10

Getting upstream targetcli-fb running on Debian 9
by Thomas Glanzmann 18 Aug '17

18 Aug '17

Hello, I would like to use the upstream version of targetcli-fb in order to be able to use the ALUA commands on a Debian 9 strech system. I cloned the git repos of rtslib-fb, configshell-fb, and targetcli-fb and ran python setup.py install Both with python and python3. I also tried to run it inside a virtualenv. When I start targetcli I get: (debian) [~] targetcli [Errno 22] Invalid argument When I trace it it seems that 'output.write(text)' is triggering the issue. Any ideas or instructions how to build this? --- modulename: console, funcname: raw_write console.py(142): output.write(text) [Errno 22] Invalid argumentconsole.py(143): output.flush() console.py(161): if not no_lf: console.py(162): self.raw_write('\n', output=output) --- modulename: console, funcname: raw_write console.py(142): output.write(text) console.py(143): output.flush() targetcli(84): if not is_root:targetcli(86): sys.exit(-1) --- modulename: trace, funcname: _unsettrace trace.py(77): sys.settrace(None) Does someone have instructions for me to get the upstream targetcli running on Debian 9 or can someone provide me with build instruction on another Linux distribution where it simply works? If you need access to a Debian 9 VM to test it by yourself, please send me your ssh key, and I provide you access to a VM. Cheers, Thomas

2 7

Re: Presenting one file backed volume Active Optimized over one tpg and Standby over another using Debian strech
by Thomas Glanzmann 18 Aug '17

18 Aug '17

Hello, * Thomas Glanzmann <thomas(a)glanzmann.de> [2017-08-17 20:47]: > So what is the best way under Debian 9 strech to create a second alua group, > set it to standby and set one of the two tpgs to the new alua group while > removing it from the default group? the current version of targetcli does not run on Debian 9. The fastest way to obtain the same is to install fedora server. There is a pretty recent version of targetcli which supports alua. In order to do the setup the following commands need to be executed: # create a standby alua group cd /backstores/fileio/shared-01.v102.tuvl.de/alua/ create standby tag=1 set alua alua_access_state=2 # Assign one LUn the standby alua group: cd /iscsi/iqn.2013-03.de.tuvl.v102.storage:shared-01.v102.tuvl.de/tpg2/luns/lun10 set alua alua_tg_pt_gp_name=standby Afterwards it looks like that: /> ls o- / ......................................................................................................................... [...] o- backstores .............................................................................................................. [...] | o- block .................................................................................................. [Storage Objects: 0] | o- fileio ................................................................................................. [Storage Objects: 1] | | o- shared-01.v102.tuvl.de .................................... [/iscsi1/shared-01.v102.tuvl.de (10.0GiB) write-back activated] | | o- alua ................................................................................................... [ALUA Groups: 2] | | o- default_tg_pt_gp ....................................................................... [ALUA state: Active/optimized] | | o- standby ......................................................................................... [ALUA state: Standby] | o- pscsi .................................................................................................. [Storage Objects: 0] | o- ramdisk ................................................................................................ [Storage Objects: 0] o- iscsi ............................................................................................................ [Targets: 1] | o- iqn.2013-03.de.tuvl.v102.storage:shared-01.v102.tuvl.de ........................................................... [TPGs: 2] | o- tpg1 .................................................................................................. [gen-acls, no-auth] | | o- acls .......................................................................................................... [ACLs: 0] | | o- luns .......................................................................................................... [LUNs: 1] | | | o- lun10 ............................. [fileio/shared-01.v102.tuvl.de (/iscsi1/shared-01.v102.tuvl.de) (default_tg_pt_gp)] | | o- portals .................................................................................................... [Portals: 1] | | o- 10.102.227.143:3260 .............................................................................................. [OK] | o- tpg2 .................................................................................................. [gen-acls, no-auth] | o- acls .......................................................................................................... [ACLs: 0] | o- luns .......................................................................................................... [LUNs: 1] | | o- lun10 ...................................... [fileio/shared-01.v102.tuvl.de (/iscsi1/shared-01.v102.tuvl.de) (standby)] | o- portals .................................................................................................... [Portals: 1] | o- 10.102.2.0:3260 .................................................................................................. [OK] o- loopback ......................................................................................................... [Targets: 0] o- vhost ............................................................................................................ [Targets: 0] The ESX server reflects the same. I found no documentation on this, is there any? Cheers, Thomas

1 0

targetcli delay shoots up as number of entries increase in a node
by Prasanna Kalever 12 Aug '17

12 Aug '17

Hi all, I have noticed, overall creation time of a block using targetcli in bash mode is raising linearly as the block count increase. 1st block create took ~1 sec 1000th block create taking up to 1m 45 sec The delay is seen from targetcli command (exec in a bash mode), a saveconfig command takes about ~ 13 sec. Eg: when there are ~100 entries, a get global takes ~6 sec # time targetcli get global [...] real 0m5.880s user 0m4.487s sys 0m1.389s On an strace on "targetcli get global" noticed targetcli reads all entries under "/sys/kerel/config/target/*", IMO which might be too much of reading/loop over for a get global ? More than a month before Mike(CCed) helped in analyzing this delay, according to him on each targetcli create call rtslib will rebuild its bs_cache, so as the /sys/kernel/config/target/core dir gets more entries this takes longer and longer to scan. This does not happen if we open targetcli in interactive mode and just do multiple create commands form it, since the bs_cache is not resetup every call. But in our use case, scripts (written using bash mode of targetcli) will be called when a block request polls in, so we need to operate targetcli in bash mode. Are there any proposed solutions for bringing down this delay ? at least if we can cut down the delay by few sec, even that will be a great start :-) Myself I'm not familiar with targetcli code, but hope to read and understand this interesting piece in the near future. I have attached the data, BlockCreatePlot.png: graph that shows the linear raise of delay while create blockCreateTime.txt: data used to generate the chart targetcliCommandDelay.txt: 'time' command output on each targetcli command, which are used to create and export a block device Thanks, -- Prasanna

2 2

[rtslib-fb] Support for TPG tags equal 0
by Fabian Bmn 06 Apr '17

06 Apr '17

Good morning, i recently made an iSCSI configuration with two TPGs. One of them had the ID 16, the other had the ID 0. When i opened targetcli, RTSLib raised the following error: "The TPG tag must be >0." Could you explain this behaviour? For my setup, i changed the "target.py" of RTSLib, so that it supports the TPG tag 0. Maybe some others could find that useful, too. I added the python script to this mail, as i don't know how to make a proper patch. (I'm a IT trainee :-) ) Feel free to give any feedback. Best regards, Fabian Baumanis

1 0

How to determine hex address for srpt acls, /sys/class/infiniband/mlx4_0/ports/1/gids/0 isn't it
by james harvey 14 Mar '17

14 Mar '17

I'm at a loss on how to get the hex address to go underneath acls when setting up srpt. If I use the fe80 prefix I see everywhere including /sys, it gets rejected. If I use the prefix shown in the kernel rejection method, which I can't find anywhere else, it works fine. targetcli configuration: /> ls o- / ......................................................................................................................... [...] o- backstores .............................................................................................................. [...] | o- block .................................................................................................. [Storage Objects: 3] | | o- kvm1 .................................................................... [/dev/disk1/kvm1 (100.0GiB) write-thru activated] | | o- kvm2 .................................................................... [/dev/disk2/kvm2 (100.0GiB) write-thru activated] | | o- kvm3 .................................................................... [/dev/disk3/kvm3 (100.0GiB) write-thru activated] | o- fileio ................................................................................................. [Storage Objects: 0] | o- pscsi .................................................................................................. [Storage Objects: 0] | o- ramdisk ................................................................................................ [Storage Objects: 0] o- iscsi ............................................................................................................ [Targets: 0] o- loopback ......................................................................................................... [Targets: 0] o- sbp .............................................................................................................. [Targets: 0] o- srpt ............................................................................................................. [Targets: 1] | o- ib.fe800000000000000002c90300001679 ........................................................................... [no-gen-acls] | o- acls ............................................................................................................ [ACLs: 1] | | o- ib.fe800000000000000002c90300001e79 .................................................................... [Mapped LUNs: 3] | | o- mapped_lun0 .................................................................................... [lun0 block/kvm1 (rw)] | | o- mapped_lun1 .................................................................................... [lun1 block/kvm2 (rw)] | | o- mapped_lun2 .................................................................................... [lun2 block/kvm3 (rw)] | o- luns ............................................................................................................ [LUNs: 3] | o- lun0 ..................................................................................... [block/kvm1 (/dev/disk1/kvm1)] | o- lun1 ..................................................................................... [block/kvm2 (/dev/disk2/kvm2)] | o- lun2 ..................................................................................... [block/kvm3 (/dev/disk3/kvm3)] o- vhost ............................................................................................................ [Targets: 0] o- xen_pvscsi ....................................................................................................... [Targets: 0] NOTE my InfiniBand cards have similar IDs, and only differ by one character -- compare the end, 1679 vs 1e79. On the target (host): $ cat /sys/class/infiniband/mlx4_0/ports/1/gids/0 fe80:0000:0000:0000:0002:c903:0000:1679 {It's my understanding this should be used underneath srpt, as the wwn} On the initiator (client): $ cat /sys/class/infiniband/mlx4_0/ports/1/gids/0 fe80:0000:0000:0000:0002:c903:0000:1e79 {It's my understanding this should be used underneath acls, and mapped with the luns} # ibsrpdm -c id_ext=0002c90300001678,ioc_guid=0002c90300001678,dgid=fe800000000000000002c90300001679,pkey=ffff,service_id=0002c90300001678 {so, its /etc/srp_daemon.conf is just comments and the line} a id_ext=0002c90300001678,ioc_guid=0002c90300001678,dgid=fe800000000000000002c90300001679,pkey=ffff,service_id=0002c90300001678 But, after starting service target on the target, and service srpdaemon on the initiator, dmesg on target shows: [ 849.710278] ib_srpt Received SRP_LOGIN_REQ with i_port_id 0x7916000003c90200:0x2c90300001e79, t_port_id 0x2c90300001678:0x2c90300001678 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c90300001679) [ 849.714528] ib_srpt Session : kernel thread ib_srpt_compl (PID 24481) started [ 849.714601] ib_srpt Rejected login because no ACL has been configured yet for initiator 0x7916000003c902000002c90300001e79. [ 849.714613] ib_srpt Session 0x7916000003c902000002c90300001e79: kernel thread ib_srpt_compl (PID 24481) stopped And, dmesg on initiator shows: [ 976.616221] scsi host11: ib_srp: REJ received [ 976.616229] scsi host11: ib_srp: SRP LOGIN from fe80:0000:0000:0000:0002:c903:0000:1e79 to fe80:0000:0000:0000:0002:c903:0000:1679 REJECTED, reason 0x00010001 [ 976.616269] scsi host11: ib_srp: Connection 0/4 failed [ 976.616276] scsi host11: ib_srp: Sending CM DREQ failed Why is the target machine, in the srp context only, seeing the ports as starting with 0x7916000003c90200 and 0x2c90300001678, and the client machine seeing the ports as starting with fe80:0000:0000:0000? What are these 0x7916... and 0x2c90... prefixes, and how can I find them besides getting a rejection and looking at the kernel logs? I haven't seen these prefixes anywhere else on either system. In targetcli, if I use acls with 0x7916000003c902000002c90300001e79, then everything works great.

6 11

Portal create with FQDN doesn't seem to be working as expected
by Prasanna Kalever 14 Mar '17

14 Mar '17

Hi, I have tried creating a iSCSI portal with FQDN/hostname, the creation seems to be successful, but on discovering this portal from the initiator fails both with IP address and hostname. On Server Side: [root@dhcp35-109 ~]# hostname dhcp35-109.lab.eng.blr.redhat.com [root@dhcp35-109 ~]# targetcli /iscsi/iqn.2016-12.org.gluster-block:8e318ce8-ba05-4ccd-bc09-0083b1f15a6c/tpg1/portals create dhcp35-109.lab.eng.blr.redhat.com ip_port=3260 Using default IP port 3260 Created network portal dhcp35-109.lab.eng.blr.redhat.com:3260. Initiator Side: [root@dhcp35-139 ~]# iscsiadm --mode discovery --type sendtargets --portal dhcp35-109.lab.eng.blr.redhat.com -l iscsiadm: cannot make connection to 10.70.35.109: Connection refused iscsiadm: cannot make connection to 10.70.35.109: Connection refused iscsiadm: cannot make connection to 10.70.35.109: Connection refused iscsiadm: cannot make connection to 10.70.35.109: Connection refused iscsiadm: cannot make connection to 10.70.35.109: Connection refused iscsiadm: cannot make connection to 10.70.35.109: Connection refused iscsiadm: connection login retries (reopen_max) 5 exceeded iscsiadm: Could not perform SendTargets discovery: encountered connection failure I have cross checked creating the portal with IP address the next time, the discovery seems to be successful. On Server Side: [root@dhcp35-109 ~]# targetcli /iscsi/iqn.2016-12.org.gluster-block:8e318ce8-ba05-4ccd-bc09-0083b1f15a6c/tpg1/portals create 10.70.35.109 ip_port=3260 Using default IP port 3260 Created network portal 10.70.35.109:3260. Initiator Side: [root@dhcp35-139 ~]# iscsiadm --mode discovery --type sendtargets --portal dhcp35-109.lab.eng.blr.redhat.com -l 10.70.35.109:3260,1 iqn.2016-12.org.gluster-block:8e318ce8-ba05-4ccd-bc09-0083b1f15a6c Logging in to [iface: default, target: iqn.2016-12.org.gluster-block:8e318ce8-ba05-4ccd-bc09-0083b1f15a6c, portal: 10.70.35.109,3260] (multiple) Login to [iface: default, target: iqn.2016-12.org.gluster-block:8e318ce8-ba05-4ccd-bc09-0083b1f15a6c, portal: 10.70.35.109,3260] successful. Is there any existing tracker for this ? Else will it worth to raise a github issue ? Thanks, -- prasanna

1 0

HEADS UP: tarballs for targetcli, rtslib, and configshell likely moving
by Andy Grover 01 Mar '17

01 Mar '17

We have been publishing tarballs for these packages at https://fedorahosted.org/released/targetcli-fb/ for a long time. Fedorahosted.org is now end-of-lifed, so future tarballs will no longer be available there (although previous releases still seem to be available for the moment.) I'm looking to see if we can just rely on GitHub release tarballs based on tags. There were some issues that prevented us using them in the past, but maybe things are better now. While I look into that, I just wanted to mention it in case anybody had some alternate ideas or input on what course would be best to take. Thanks -- Regards -- Andy

1 0

what is the best way to configure LIO through c or c++ program?
by spardeshi＠commvault.com 07 Feb '17

07 Feb '17

I have been using targetcli to play around with LIO. I need to configure the LIO targets, backstores, luns etc through c or c++ program. There are multiple ways to achieve that - use targetcli. It is easy but then you are invoking python from the c/c++ program and have to parse the targetcli output. I am not thrilled about parsing text output and i am not sure how granular it is (in terms of configFS attributes). Also, it has python dependency. - use configFS directly. That means, interact with the kernel drivers directly. It gives more control but i am not sure how frequently configFS LIO attributes change from one release to another and what is backward compatibility? - i would prefer some c lib which i can link to. But i didn't come across one yet

2 1

how to add user backed storage object (file example) as a lun to iscsi target?
by spardeshi＠commvault.com 02 Feb '17

02 Feb '17

I am running following versions kernel 4.9.6 tcmu-runner-1.2.0 targetcli 2.1.fb41-3.el7 rtslib 2.1.fb57-5.el7 configshell 1:1.1.fb18-1.el7 And i am running tcmu-runner from command line. Also created user backed storage object (file example) using instructions in readme (shown below), it created the file backed user storage object. mkdir -p /sys/kernel/config/target/core/user_1/test cd /sys/kernel/config/target/core/user_1/test echo -n dev_size=16777216 > control echo -n dev_config=file//lio/file0 echo -n 1 > enable How do add this user backed storage object to a lun? I don't see any option in targetcli to add user backed storage object as a lun. [root@centostemplate tcmu-runner-1.2.0]# 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.centostemplate.x8664:sn.2537ca9036c0 .................................................. [TPGs: 1] | o- tpg1 .................................................................................................. [gen-acls, no-auth] | o- acls .......................................................................................................... [ACLs: 0] | o- luns .......................................................................................................... [LUNs: 0] | o- portals .................................................................................................... [Portals: 1] | o- 0.0.0.0:3260 ..................................................................................................... [OK] o- loopback ......................................................................................................... [Targets: 0] />

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

targetcli-fb-devel