Two hosts can reach the same LUN, and sg_persist is how you make sure only one of them is allowed to write to it. By the end of this guide you will be able to inspect a SCSI device's persistent reservations, register a key, create a reservation, and release it, without confusing a read-only query with a state-changing command. Allow 10 to 20 minutes for inspection; changes need a planned maintenance window and a second check from every host that can reach the LUN.
sg3-utils and identify the exact SCSI device. Use a SCSI generic path such as /dev/sg2 when you have one, or a block-device path such as /dev/sdb if that is what your system exposes./dev/sgX in every example. Do not guess: a persistent reservation applies to the target logical unit and can disrupt another host.sg_persist --help on the machine where you will run a change, because short-option details can differ between builds.The installed package on this system is sg3-utils 1.46-3ubuntu4. The binary reports 0.67 20190913, while the installed manpage footer says sg3_utils-1.43.
sg_persist --version
sg_persist --help
Queries usually need permission to open the device, but they do not need to change the reservation. If the device node is restricted, prefix the query with sudo. The registration, reservation, release, and clear examples below use sudo because they normally require elevated access.
Start with the default operation. With no service-action option, sg_persist sends a Persistent Reserve In command using Read Keys. It lists reservation keys already registered with the logical unit. The standard inquiry runs first unless you select --no-inquiry.
sudo sg_persist --read-keys /dev/sgX
Expected output depends on the device. A successful response includes inquiry information followed by decoded persistent-reservation data. The useful result is a list of keys, which may be empty: an empty list means no registrations were reported, it does not prove the device is unused.
Checkpoint: Record the device path and the keys shown. If the target is shared, collect this result from the other initiators before making a change.
Read the current holder with --read-reservation. This reports the reservation key, scope, and type, or says there is no current reservation.
sudo sg_persist --read-reservation /dev/sgX
sudo sg_persist --report-capabilities /dev/sgX
For more detail about every registration, use Read Full Status. The output can include the reservation key and decoded TransportID information for each initiator.
sudo sg_persist --read-full-status /dev/sgX
These are Persistent Reserve In queries: they do not need --out. The confusing duplicate short option -s is documented for both full status spellings on this installation, so the explicit long form is easier to review in a change record.
A persistent reservation has two stages. First, the initiator registers a reservation key. Second, it uses that key to reserve the logical unit. Pick a non-zero hexadecimal key that your operational process can identify, such as 123abc. Do not reuse a key belonging to another initiator.
Warning: this is the first state-changing command. Registration changes the device's shared coordination state, although it does not by itself reserve the device. Confirm the path and key immediately before running it.
sudo sg_persist --out --register \
--param-sark=123abc /dev/sgX
The --out option is deliberate: sg_persist requires it as a safety gate for Persistent Reserve Out operations. A successful command normally returns no error; verify the registration instead of treating silence as proof.
sudo sg_persist --read-keys /dev/sgX
The key values are hexadecimal. --param-rk identifies the existing key for the current initiator, while --param-sark supplies the new or service-action key. When adding a registration, an omitted --param-rk has the documented default of zero.
Once the registration is visible, reserve the logical unit with a type that matches your design. Type 1 is write exclusive: it lets the registering initiator hold the reservation while preventing conflicting writes from other initiators.
Warning: a reservation can make commands from other hosts fail with a reservation conflict. Stop application I/O or follow the storage vendor's cluster procedure before running this command.
sudo sg_persist --out --reserve \
--param-rk=123abc --prout-type=1 /dev/sgX
Verify both sides of the state:
sudo sg_persist --read-reservation /dev/sgX
sudo sg_persist --read-full-status /dev/sgX
The reservation key should be 123abc, and the reservation type should be reported as write exclusive. The exact wording is device and version dependent, so compare the key and type rather than copying an expected line verbatim.
Release uses the same key and reservation type used to create the reservation. This removes the active reservation but leaves the registration in place.
sudo sg_persist --out --release \
--param-rk=123abc --prout-type=1 /dev/sgX
After releasing it, verify there is no current reservation:
sudo sg_persist --read-reservation /dev/sgX
To unregister only this initiator's key, use Register with the old key as --param-rk and a zero service-action key. This is easy to misread because the command still says --register.
sudo sg_persist --out --register \
--param-rk=123abc --param-sark=0 /dev/sgX
Confirm the key has disappeared:
sudo sg_persist --read-keys /dev/sgX
Warning: do not substitute --clear unless you intend to release the reservation and remove every registration from the logical unit. Clear is broader and can disrupt other initiators.
--readonly opens the device read-only and can be useful for Persistent Reserve In queries when a read-write open has unwanted side effects.--replace-lost operation exists for an application-managed recovery process, but its key and type requirements must match the device's reservation design; use it only with the storage or cluster recovery procedure in hand.--clear only when removing every registration was intentional.