Oracle ZFS Storage Appliance: NDMP - Unknown GUID during LUN Restore

Asset ID:	1-72-1947661.1
Update Date:	2018-01-08
Keywords:

Solution Type Problem Resolution Sure

Solution 1947661.1 : Oracle ZFS Storage Appliance: NDMP - Unknown GUID during LUN Restore

Applies to:

Sun ZFS Storage 7120 - Version All Versions to All Versions [Release All Releases]
Sun Storage 7310 Unified Storage System - Version All Versions to All Versions [Release All Releases]
Oracle ZFS Storage ZS3-4 - Version All Versions to All Versions [Release All Releases]
Sun ZFS Storage 7320 - Version All Versions to All Versions [Release All Releases]
Sun Storage 7410 Unified Storage System - Version All Versions to All Versions [Release All Releases]
7000 Appliance OS (Fishworks)

Symptoms

An NDMP restore completed successfully, but the LUN is created by the ZFS appliance with unknown GUID

Cause

The specific GUID is already used by an existing LUN.

akd.ak

Mon Jul 21 09:03:14 2014: GUID for LU opscenter/local/Ops-LUNs/ldom-c-4-boot1_restore2 is already in use; importing with new GUID
Mon Jul 21 09:03:14 2014: Validation Failed , view list info (guid:hg:tg:lun) - 600144F088E2E046000053AA8E7E0079:opsCenterIscsi:OC-iSCSI:182 ; 600144F088E2E046000053CCD7520005:opsCenterIscsi:OC-iSCSI:182 - view count=2, err: 0x800e (view entry conflict)
Mon Jul 21 09:03:14 2014: LU 600144F088E2E046000053CCD7520005 deleted on view failure
Mon Jul 21 09:03:14 2014: failed to mount opscenter/local/Ops-LUNs/ldom-c-4-boot1_restore2: {txtid:"AKTXT_XMLRPC_STMF_VE_CONFLICT", args: [" 600144F088E2E046000053AA8E7E0079"]}

Bug 19463915 - GUID of a NDMP restored LUN is 'unknown' due to AKTXT_XMLRPC_STMF_VE_CONFLICT

> zvol created by the zfs restore inherits the "com.sun.ak:stmfoptions" property from the source.

> This property contains lu-view info - host group, target group, lunumber and lun assigned number.
> When system attempts to import a volume with a lun assigned number that matches the existing lun with the same host and target groups, STMF will fail
> to add a view and GUID will be set to "unknown".
>
> This issue could be resolved by removing the lun assigned number from the destination dataset's stmfoptions property once restore is completed before mounting it.
> This makes STMF to auto assign a new lun during import.

Solution

Upgrade ZFS Appliance to firmware code 8.5.0 or above

As a workaround - remove the original LUN before restoring.

Alternatively try this workaround by assigning a new LUN assigned number and re-export the LUN with new LUN guid.

In CLI do the following:

1. Go to the lun with unknown GUID

shares select <projectname/share> select lun-name

2. Verify that this is the correct LUN:

get lunguid
lunguid = <unknown>

3. Check assigned lun number:

get assignednumber
assignednumber = 9

4. Set assigned number to first free lun# in the target-group.
   do "ggrep -A 2 'Target Group : target-groupname ' iscsi/stmf_views.out in a bundle)
   Example: In the latest bundle luns 0-10 are occupied in the target-group)
           set assignednumber=11

5. Stop exporting of this lun temporarily:

set exported=false

6. Save changes(ie save new lun# and disable export)

commit

7. Export the lun again and save changes

set export=true
commit

8. The end.

Now the LUN should have a GUID and be visible from the client side.

Please note that there may be some procedure needed on the client to rescan the LUN's and if the LUN# is used to determine the drive instead of the GUID some config changes may be needed for the LUN to appear "in the correct place"

References

<NOTE:1387930.1> - Sun Storage 7000 Unified Storage System: How to Troubleshoot NDMP Issues
<BUG:19463915> - GUID OF A NDMP RESTORED LUN IS 'UNKNOWN' DUE TO AKTXT_XMLRPC_STMF_VE_CONFLICT

Attachments

This solution has no attachment