First, let's verify the iSCSI target service is running correctly:

# Check tgtd service status
service tgtd status

# List configured targets
tgt-admin --show

# Expected output should show both targets with proper LUNs

The difference in LUN visibility indicates a potential configuration issue. Here's how to analyze it:

# Detailed view of specific target
tgt-admin --show --target iqn.2013-08.com.example.group:migrations

# Check system logs for errors
tail -n 50 /var/log/messages | grep -i iscsi

iSCSI uses TCP port 3260. Verify connectivity:

# Check listening ports
netstat -tulnp | grep 3260

# Test connectivity from initiator
nc -zv <target_ip> 3260

The incominguser directive might require additional parameters:

# Example working authentication config
<target iqn.2013-08.com.example.group:backup>
  backing-store /dev/primary/backup
  initiator-address <ip_address>
  incominguser username password
  write-cache off
</target>

When basic checks don't reveal the issue, try these:

# Increase logging verbosity
tgt-admin --foreground --debug 8

# Alternative discovery method
iscsiadm -m discovery -t st -p <target_ip> -I default -l

For reliable iSCSI target setup:

1. Always specify explicit LUN numbers
2. Use consistent naming conventions
3. Document initiator-target mappings
4. Configure persistent logging

# Example of explicit LUN configuration
<target iqn.2013-08.com.example.group:migrations>
  backing-store /dev/primary/migrations
  lun 1
  initiator-address <ip_address>
</target>

---

When working with iSCSI configurations on CentOS 6.4, I encountered a peculiar situation where one target was discoverable while another remained invisible to initiators. The setup involved:

# Sample problematic configuration:
<target iqn.2013-08.com.example.group:migrations>
  backing-store /dev/primary/migrations
  initiator-address 192.168.1.100
  incominguser iscsiuser securepass123
</target>

The output from tgt-admin -s showed inconsistent LUN presentation between targets. For the working target:

Target 1: iqn.2013-08.com.example.group:backup
    LUN: 0 (Controller)
    LUN: 1 (Disk /dev/primary/backup)

For the problematic target:

Target 2: iqn.2013-08.com.example.group:migrations
    LUN: 0 (Controller)

Several critical configuration elements need verification:

1. Target IQN naming convention compliance
2. Proper LUN mapping in target configuration
3. Correct permissions on backing storage devices
4. Firewall/SELinux considerations

1. Verify Target Service Status

service tgtd status
tgt-admin --show

2. Check for Configuration Errors

tgt-admin --verify --config /etc/tgt/targets.conf

3. Manual Target Creation Test

Try creating the target interactively:

tgtadm --lld iscsi --mode target --op new --tid 2 --targetname iqn.2013-08.com.example.group:test
tgtadm --lld iscsi --mode logicalunit --op new --tid 2 --lun 1 --backing-store /dev/primary/migrations
tgtadm --lld iscsi --mode target --op bind --tid 2 --initiator-address 192.168.1.100

Issue	Solution
Missing LUN presentation	Explicitly add LUN mapping in config
Incorrect initiator address	Verify IP and network connectivity
SELinux blocking access	setsebool -P daemons_use_tcp 1
Firewall restrictions	Open TCP ports 3260, 860

After troubleshooting, the corrected configuration looks like:

<target iqn.2013-08.com.example.group:migrations>
  backing-store /dev/primary/migrations
  lun 1
  initiator-address 192.168.1.100
  incominguser iscsiuser securepass123
</target>

Key changes included:

• Explicit LUN numbering
• Verified backing store permissions
• Disabled restrictive SELinux policies