Oracle ZFS Storage Appliance : Unable To Unconfigure an 'empty' Pool

Asset ID:	1-72-1958529.1
Update Date:	2015-11-05
Keywords:

Solution Type Problem Resolution Sure

Solution 1958529.1 : Oracle ZFS Storage Appliance : Unable To Unconfigure an 'empty' Pool

Applies to:

Sun Storage 7410 Unified Storage System - Version All Versions and later
Oracle ZFS Storage ZS3-4 - Version All Versions and later
Oracle ZFS Storage ZS3-BA - Version All Versions and later
Sun ZFS Storage 7120 - Version All Versions and later
Sun ZFS Storage 7320 - Version All Versions and later
7000 Appliance OS (Fishworks)

Symptoms

While trying to remove a pool from a ZFS appliance, an error message is displayed that indicates that the pool is still 'in use':

The action could not be completed because the target 'DATAPOOL' is in use. It cannot be modified while it, or its children, are actively changing.Make sure no other users are editing the share configuration and try again. If this problem persists, contact your service provider.

If an attempt is made to add a new filesystem, 'no such dataset or pool' is displayed:

12:22:24.449Exception type: coXmlrpcFault
Native message: call for param #1 to system.push failed: call for param #1 to array.create failed: no such dataset or pool
Native file: <undefined> line ?
Additional native members:
faultCode: 263
faultString: call for param #1 to system.push failed: call for param #1 to array.create failed: no such dataset or pool
faultData: [object Object]
coStack: <unknown>(argv:<array> "[object Object],[object Object],[object Object]", abort:true, func:<function> "function (ret, err, ndx) {\n\t\tif (err) {\n\t\t\tfunc(undefined, err);\n\t\t\tthrow (err);\n\t\t}\n\n\t\tid = ret[call.length - 1][0];\n\t\tprocess(ret[call.length - 2][0]);\n\t}")
<unknown>(method:<object> "[object Object]", func:<function> "function (ret, err) {\n\t\takStopWaiting();\n\t\tif (view.handleError(err, view.nsv_target))\n\t\t\treturn;\n\n\t\tvar retprop = new Object();\n\t\tview.nsv_projects = new Array();\n\t\tfor (var i = 0; i < ret.length; i++) {\n\t\t\tview.nsv_projects.push(ret[i]['com.sun.ak:project']);\n\t\t\tretprop[ret[i]['com.sun.ak:project']] = ret[i];\n\t\t}\n\n\t\tcallback(view.nsv_projects, retprop);\n\t }", progress:null)
<unknown>(callback:<function> "function (projects) {\n\t\tdialog = new nasCreateDialog(view, type, projects,\n\t\t conf.callback, conf.defaults);\n\t\tdialog.loadDefaults(show);\n\t}", properties:null)
<unknown>(view:[akv_current.akv_view], type:"filesystem", conf:null)
<unknown>(<object> "[object Object]", <object> "[object MouseEvent]")
<unknown>(e:<object> "[object MouseEvent]")

Cause

A pool cannot be exported as long as its volumes are shared as iSCSI LUNs.

A ZFS volume as an iSCSI target is managed just like any other ZFS dataset, except that you cannot rename the dataset, roll back a volume snapshot, or export the pool while the ZFS volumes are shared as iSCSI LUNs.

A bug appears to have prevented akd from deleting the iSCSI LUN mappings (CR 17456206 - still under investigation).

It looks like a timing issue, as if the "zfs destroy" did not wait for the LUN mappings to be deleted. The mappings do get deleted but they get immediately recreated.

Solution

Recommended action for the customer:

To remove the iSCSI LUN mappings, you will need to engage Oracle Support, by opening a Service Request, so that Oracle Support Services can provide confirmation of this issue and then carry out the appropriate activities to resolve the issue.

Recommended actions for the Oracle Support engineer:

To delete the iSCSI LUN mappings - see the following wiki document:

https://stbeehive.oracle.com/teamcollab/wiki/AmberRoadSupport:Shared+shell+procedure+to+delete+LUN+mappings+to+allow+pool+destruction

If you cannot access this document engage NAS Storage-TSC for assistance

NOTE: A similar issue and the above error message can be observed, if a zpool delete process is running.

The deletion of data in a ZFS pool can take a long time, and while the data appears to be deleted, the actual delete process is still running in background.

NAS Engineer note:

To determine that the delete is in progress this mdb command can be run:

echo "::stacks -c dmu_objset_destroy" | mdb -k

If thread data is returned by the mdb command, then there is still a delete running.

If nothing is returned, then there is no delete running at this time.

Attachments

This solution has no attachment