One command can discover a portal, log in, and decide whether the login survives a reboot: iscsi_discovery does all three in a single privileged step. You will discover targets, understand whether the command leaves a persistent automatic-login record, and choose whether the newly found node stays logged in. The examples use iscsi_discovery from open-iscsi 2.1.9, installed here as Debian package version 2.1.9-3ubuntu5.4.
Allow about fifteen minutes, plus the time needed to get the correct portal address from your storage administrator. You need a shell, the open-iscsi package, a reachable iSCSI portal, and root privileges for the discovery operation. This guide does not create a filesystem, format a LUN, mount storage or remove an existing node.
Confirm which executable and package version you are about to use. These are ordinary, read-only checks:
$ command -v iscsi_discovery
/usr/sbin/iscsi_discovery
$ dpkg-query -W -f='${Package} ${Version}\n' open-iscsi
open-iscsi 2.1.9-3ubuntu5.4The manual requires the open-iscsi services to be running, in particular iscsid, and says the iSCSI kernel modules must be loaded. Check the daemon before attempting discovery:
$ systemctl is-active iscsid
activeIf the result is not active, stop here and use your distribution's normal service-management procedure. Starting or enabling a service changes system state and may affect other storage operations, so do not add an unreviewed systemctl enable or restart command to a production runbook.
Checkpoint: you have the portal address, the daemon is active, and you know which open-iscsi version is installed.
The required argument is the portal IP address. The default TCP port is 3260, and the default transport request is tcp. Discovery needs elevated privileges because it talks to the local iSCSI services and may create node configuration:
# iscsi_discovery 192.0.2.10
Replace 192.0.2.10 with the address supplied for your environment. The command performs send-targets discovery, and when it receives a discovery record it tries to log in through the portal using the requested transport. Do not use an address copied from an untrusted message without checking that it is the intended storage network.
A successful run normally prints discovery and login information from the underlying iSCSI tools. Exact lines depend on the target, network and installed open-iscsi helpers, so treat the command's exit status as the first check:
# iscsi_discovery 192.0.2.10
# printf 'iscsi_discovery exit status: %s\n' "$?"
iscsi_discovery exit status: 0Status zero means this invocation completed successfully. It does not prove the intended LUN is safe to use. Do not format or mount anything merely because discovery worked.
Pass the portal port with -p. The manual accepts either -p PORT or -p=PORT syntax:
# iscsi_discovery 192.0.2.10 -p 3261
# printf 'iscsi_discovery exit status: %s\n' "$?"
iscsi_discovery exit status: 0Use the port documented for this target, not a port scan result. A reachable service on the wrong port is not evidence it is an iSCSI portal. If discovery fails, check routing and firewall policy with the network administrator, then confirm the address and port rather than repeatedly retrying.
TCP is the default transport. Request it explicitly when you want the command line to document that choice:
# iscsi_discovery 192.0.2.10 -t tcp
The other documented transport value is iser. Without -f, the command can fall back to TCP if the requested transport does not succeed. Add -f only when using another transport is a requirement and a TCP fallback would be unsafe or misleading:
# iscsi_discovery 192.0.2.10 -t iser -f
-f forces the transport specified with -t; it is not a general force-discovery switch. If you use -t iser, verify the host and target actually provide the required iSER support before running the command.
After a successful transport login, the default behaviour marks the portal for automatic login and then disconnects. That gives you a persistent node record without leaving this discovery session connected. Review the node records through your normal open-iscsi administration process before relying on a reboot to reconnect them.
Use -m when the node should use manual startup instead:
# iscsi_discovery 192.0.2.10 -m
This is a configuration change. It does not delete an existing node record, and it does not turn off every possible login path already configured on the host. If you discover the same portal more than once, inspect the resulting records rather than assuming the newest command replaced all older settings.
Use -l when you want the newly discovered nodes to remain logged in:
# iscsi_discovery 192.0.2.10 -l
Warning: that can expose block devices to the host immediately. Before using -l, confirm that multipath, filesystem ownership and application expectations are already understood. Never mount a newly presented device by guessing its name: identify it from the target and host storage policy first.
If the command reports that iscsid is not running, return to step 1. If it cannot reach the portal, verify the IP address, selected port, route and firewall rules. If a requested transport fails, retry with the storage administrator's approved transport choice; do not silently switch to TCP when the transport is part of the design.
Use -d for debugging information when a normal run does not explain the failure:
# iscsi_discovery 192.0.2.10 -d
Debug output can include target and network details. Treat it as sensitive operational information and avoid pasting it into a public issue or chat. If a run changed a node's automatic or manual startup setting unexpectedly, stop making further discovery attempts. Record the exact command and consult the open-iscsi node configuration through your approved change process; do not delete files from its configuration directory as an improvised undo.
iscsid was active before discovery began.-l only when an immediate login was planned and safe.