Safely Trespass an EMC LUN with sg_emc_trespass

You will finish with a controlled way to send an EMC Trespass Command to a SCSI LUN, moving its ownership from the peer Service-Processor to the one that receives the command. This is a storage failover operation, not a routine disk probe. Run it only when your array design and recovery plan say that this host should take ownership.

Allow about fifteen minutes for the command and checks, plus whatever maintenance window your storage team requires. You need the sg3-utils package, an EMC CLARiiON CX or AX family array, or one of the supported FC series arrays, and the correct device path. The installed package here is sg3-utils 1.46-3ubuntu4; sg_emc_trespass -V reports program version 0.23 20180219.

1. Confirm the command and the target

Start with read-only checks. Ordinary users can run these unless your host restricts access to device metadata:

$ command -v sg_emc_trespass
/usr/bin/sg_emc_trespass
$ sg_emc_trespass -V
Version string: 0.23 20180219
$ dpkg-query -W -f='${Package} ${Version}\n' sg3-utils
sg3-utils 1.46-3ubuntu4

The utility accepts one final DEVICE argument. The manual describes an SCSI generic device as the normal target, and also permits a block device on Linux 2.6 and later. A path such as /dev/sdX below is a placeholder, not a device you should copy unchanged.

Checkpoint: identify the LUN from your storage documentation and host mapping before putting its path into a command. Do not select a device merely because it is the newest entry in lsblk. A wrong path can send the request to the wrong LUN.

2. Check the array family and command form

The default is the long Trespass Command. The manpage says this form is supported on the EMC CLARiiON CX and AX family arrays. The short form is selected with -s and is described for the EMC FC5300, FC4500 and FC4700.

Use the form that matches the array, not the form that happens to be shorter:

# Default long form for a CLARiiON CX or AX family array
$ sg_emc_trespass /dev/sgX

# Short form for a supported FC5300, FC4500 or FC4700
$ sg_emc_trespass -s /dev/sgX

These commands send a storage-control request. They are examples of the syntax only. Do not run either one until the maintenance or failover decision has been made and the device path has been independently checked.

For a block device on a suitable Linux release, the same option placement applies:

# Replace /dev/sdX with the verified LUN path
$ sg_emc_trespass /dev/sdX

The historical manpage mentions Linux 2.4, 2.6 and later kernels. The installed help describes both SCSI generic and block devices, but array and multipath support still determine whether a particular path is appropriate. The command does not discover the correct path for you.

3. Decide how reservations should be handled

By default, the trespass ignores the LUN's SCSI reservation state. Add -hr to set the reservation-protection bit:

# Only use this policy when your reservation design requires it
$ sg_emc_trespass -hr /dev/sgX

With -hr, ownership changes from the peer Service-Processor only if that peer does not hold an outstanding SCSI reservation for the LUN. Without it, the reservation state is ignored by this command. That is a consequential default: omitting -hr is not the same as asking the array to protect an existing reservation.

Do not add the option because it sounds safer. Confirm the reservation policy with the cluster, multipath and array configuration first. A reservation-aware trespass can fail when the peer still holds the reservation; ignoring reservations can violate the coordination expected by clustered hosts.

4. Warn the host and run the approved operation

Before sending the command, stop or quiesce applications that are not designed for a path or ownership change, and follow your array vendor's failover procedure. This utility changes LUN ownership at the Service-Processor. It can disrupt I/O, expose a path change to multipath software, or leave applications reporting errors while paths settle.

Run the final command with elevated privileges when the device node requires it. Keep the device path quoted if it comes from a variable, and keep options separate from the path:

# Maintenance-window example, long form, honouring reservations
$ sudo sg_emc_trespass -hr /dev/sgX

The command normally produces no success message. Its exit status is the useful immediate result:

$ status=$?
$ printf 'sg_emc_trespass exit status: %s\n' "$status"
sg_emc_trespass exit status: 0

Status 0 means the utility completed successfully. A non-zero status means the operation did not complete successfully; consult the command's diagnostic output and the broader sg3_utils(8) guidance. Do not infer that ownership changed from a quiet terminal alone.

Checkpoint: record the exact command, device path, option set, timestamp and exit status in the change record. Then verify ownership and path state using your array management interface and the host's approved multipath tooling. Those checks are environment-specific and are not performed by sg_emc_trespass.

5. Use debug output when a permitted attempt fails

Add -d to request extra debug information from the utility. Keep the operation within the same approved target and option policy:

$ sudo sg_emc_trespass -d -hr /dev/sgX
$ status=$?
$ printf 'debugged attempt exit status: %s\n' "$status"

Debug output can help separate an argument or device-opening problem from a SCSI response, but it does not make a failed trespass safe to repeat blindly. Preserve the output with the change record and compare it with the array event log. Repeating the command may be disruptive, especially if the first attempt actually changed ownership but the host-side check was delayed.

Test path access without sending a Trespass Command when you are only checking a typo:

$ sg_emc_trespass /dev/does-not-exist
Error trying to open /dev/does-not-exist
No such file or directory
$ printf 'exit status: %s\n' "$?"
exit status: 1

This example is safe because the path does not exist. It demonstrates an open failure, not an array response. Replace it with a real device only when you are ready to perform the storage operation.

6. Recover from an unsuccessful or unwanted change

There is no undo flag in sg_emc_trespass. If the result is unexpected, do not try random combinations of -s and -hr. Keep applications from issuing new I/O if your procedure requires that, inspect the array's current owning Service-Processor, review reservations and multipath state, and use the array vendor's documented trespass or failback procedure for returning ownership.

If the command returned non-zero, preserve the error text and status before running another storage command. Check that the device path still identifies the intended LUN and that the selected long or short form matches the hardware. An access error can be a permissions problem; an array rejection needs the array and reservation context. sudo can grant access to a device node, but it cannot correct a wrong LUN, unsupported array family or reservation conflict.