Safely Trespass an EMC LUN with sg_emc_trespass

sg_emc_trespass sends an EMC Trespass Command that hands a SCSI LUN's ownership to the Service-Processor receiving it. This is a storage failover operation, not a routine disk probe: run it only when your array design and recovery plan say 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 takes one final DEVICE argument. The manual treats an SCSI generic device as the normal target, and also allows a block device on Linux 2.6 and later. A path such as /dev/sdX below is a placeholder, not something to paste unchanged.

2. Check the array family and command form

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

• Match the form to the array, never to whichever one happens to be shorter to type.

# 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 are syntax examples of a storage-control request, nothing more. Do not run either one until the maintenance or failover decision is 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 covers both SCSI generic and block devices, but array and multipath support still decide whether a given path is appropriate: the command never discovers the right 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 holds no outstanding SCSI reservation for the LUN. Without it, the reservation state is ignored outright: that is a consequential default, and skipping -hr is not the same as asking the array to protect an existing reservation.

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

4. Warn the host and run the approved operation

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

Run the final command with elevated privileges if the device node requires it. Keep the device path quoted when 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, so 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 it did not; consult the diagnostic output and the broader sg3_utils(8) guidance. Never infer that ownership changed just because the terminal stayed quiet.

5. Use debug output when a permitted attempt fails

Add -d for extra debug information from the utility, keeping 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 separate an argument or device-opening problem from a SCSI response, but it does not make a failed trespass safe to repeat blindly. Keep the output with the change record and compare it against the array event log. Repeating the command can 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. Swap in a real device only once 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 not what you expected, do not start trying random combinations of -s and -hr. Instead:

• Stop new I/O if your procedure requires it.
• Inspect the array's current owning Service-Processor.
• Review reservations and multipath state.
• Use the vendor's documented trespass or failback procedure to return ownership, rather than improvising one.

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 chosen 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 fixes nothing about a wrong LUN, an unsupported array family or a reservation conflict.