RE: ctl.conf / iscsi docs and best practices

I just started working with the target again about a week ago, here is my setup.

For two remote initiators to connect to the same target you need
option "ha shared" "on"

Maybe this helps you a little.

--mikej

portal-group "pg0" {
        discovery-auth-group "no-authentication"
        listen "192.168.6.11:3260"
        listen "[::]:3260"
        option "ha_shared" "on"
}


auth-group "ag0" {
        initiator-name "iqn.1998-01.com.vmware:hv1-3972eaf3"
        initiator-name "iqn.1998-01.com.vmware:esxi2.mikej.local:980613345:64"
        initiator-name "iqn.1998-01.com.vmware:esxi3.mikej.local.:1805690011:64"
        initiator-portal "192.168.6.8"
        initiator-portal "192.168.6.14"
        initiator-portal "192.168.6.5"
        auth-type "none"
}


auth-group "ag1" {
        initiator-name "iqn.1994-05.com.unitrends:60e2f1d15e57"
        initiator-portal "192.168.6.9"
        auth-type "none"
}


lun "esxi-store1" {
        path "/dev/zvol/raid-5400-1/esxi-store1"
        blocksize "512"
        serial "YEAH RIGHT"
        device-id "iSCSI Disk"
        option "vendor" "MikeJ"
        option "product" "iSCSI Disk"
        option "revision" "0123"
        option "naa" "0x6589cfc00000079e8a0d223e935440ab"
        option "insecure_tpc" "on"
        option "rpm" "1"
}

lun "unitrends1" {
        path "/dev/zvol/raid-5400-1/unitrends1"
        blocksize "512"
        serial "YEAH RIGHT"
        device-id "iSCSI Disk"
        option "vendor" "MikeJ"
        option "product" "iSCSI Disk"
        option "revision" "0123"
        option "naa" "0x6589cfc00000079e8a0d223e935440ac"
        option "insecure_tpc" "on"
        option "rpm" "1"
}



target "iqn.2005-10.org.mikej.ctl:esxi-store1" {
        auth-group "ag0"
        portal-group "pg0"
        alias "esxi-store1"
        lun "0" "esxi-store1"
}

target "iqn.1994-05.com.unitrends:60e2f1d15e57" {
        auth-group "ag1"
        portal-group "pg0"
        alias "unitrens11"
        lun "1" "unitrends1"
}

-----Original Message-----
From: owner-freebsd-fs@freebsd.org [mailto:owner-freebsd-fs@freebsd.org] On Behalf Of mike tancsa
Sent: Monday, March 14, 2022 2:48 PM
To: freebsd-fs <freebsd-fs@freebsd.org>
Subject: ctl.conf / iscsi docs and best practices

Looking at diving deeper into FreeBSD as an iscsi target and initiator, but more so as a target server.  Looking at the handbook, there are not a lot of docs there and the sample ctl.conf entries dont really follow the style of the example ctl.conf file generated by something like TrueNAS.  Are there any better FreeBSD docs out there ? Anyone have any decent go to docs around iscsi in general that are good primers as well ? My goal is to serve up storage for a bunch of Linux KVM initiators with the iscsi targets on FreeBSD being zvols.

e.g. in TrueNAS, I see it define a bunch of individual LUNs and then targets as so.

lun "freebsd2" {
         ctl-lun "1"
         path "/dev/zvol/tankstripe/freebsd2"
         blocksize "512"
         serial "000743299890001"
         device-id "iSCSI Disk      000743299890001 "
         option "vendor" "TrueNAS"
         option "product" "iSCSI Disk"
         option "revision" "0123"
         option "naa" "0x6589cfc000000c330e3ddde42a36408a"
         option "insecure_tpc" "on"
         option "rpm" "1"
}

lun "freebsd3" {
         ctl-lun "2"
         path "/dev/zvol/tankstripe/freebsd3"
         blocksize "4096"
         serial "000743299890002"
         device-id "iSCSI Disk      000743299890002 "
         option "vendor" "TrueNAS"
         option "product" "iSCSI Disk"
         option "revision" "0123"
         option "naa" "0x6589cfc0000001cd46c021f21b31d0cc"
         option "insecure_tpc" "on"
         option "rpm" "1"
}

Then define more LUNs in the targets that reference the above LUNs

target "iqn.2005-10.org.freenas.ctl:freebsd2" {
         alias "freebsd2"
         portal-group "pg1" "ag4tg2_2"

         lun "0" "freebsd2"
}

target "iqn.2005-10.org.freenas.ctl:freebsd3" {
         alias "freebsd3"
         portal-group "pg1" "ag4tg3_3"

         lun "0" "freebsd3"
}


So the lun that refers to the block of storage also has a ctl-lun that seems to be uniq. What is the purpose of that ? Same with serial #s and Device-IDs. Are these merely informational or are they a requirement for something ?

If multiple initiators are to have sessions to the target, with only one actively writing to it, are there any special options I need to set ?

I also noticed in ctladm are several cache sync options.  My go - to zfs replication software is zrepl which has hooks that can be fired before and after a snapshot.  Do I want to send some sort of cache flush command to the target ? Or is that the guest OS' responsibility to do a sync that that the snapshot is coherent as possible.

Thanks for any pointers.

     ---Mike





CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.