JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle® ZFS Storage Appliance Administration Guide
Oracle Technology Network
Print View
search filter icon
search icon

Document Information

Using This Documentation

Chapter 1 Oracle ZFS Storage Appliance Overview

ZFSSA Key Features

Supported Protocols

ZFSSA Data Services

Data Availability

ZFSSA Configuration

Browser User Interface (BUI)

Main Window




Session Annotation

Title Bar

Side Panels and Menu Titles

Main Window Side Panels and Menu Titles

Add Projects

Move Shares

Object Name

Non-Standard BUI Control Primer


Editing Share Properties

Viewing List Item Controls

Modal Dialogs

General Usage


Basic Usage


Dashboard Thresholds


Identity Mapping

Miscellaneous Icons

Supported Browsers

Tier 1

Tier 2

Unsupported Browsers

Command Line Interface (CLI)

Logging Into the CLI

CLI Contexts

Root Context

Child Contexts

Dynamic Child Contexts

Last Context

Returning to a Previous Context

Navigating to a Parent Context

Contexts and Tab-Completion

Executing Context-Specific Commands

Uncommitted Contexts


CLI Properties

Getting Properties

Getting a Single Property Value

Tab Completion

Setting Properties

Committing a Set Property Value

Setting a Property Value with an Implied Commit

Setting a Property to a List of Values

Setting a Property to a Value Containing Special Characters

Immutable Properties

Chapter 2 Status

Chapter 3 Initial Configuration

Chapter 4 Network Configuration

Chapter 5 Storage Configuration

Chapter 6 Storage Area Network Configuration

Chapter 7 User Configuration

Chapter 8 Setting ZFSSA Preferences

Chapter 9 Alert Configuration

Chapter 10 Cluster Configuration

Chapter 11 ZFSSA Services

Chapter 12 Shares, Projects, and Schema

Chapter 13 Replication

Chapter 14 Shadow Migration

Chapter 15 CLI Scripting

Chapter 16 Maintenance Workflows

Chapter 17 Integration


CLI Contexts

A central principle in the CLI is the context in which commands are executed. The context dictates which elements of the system can be managed, and which commands are available. Contexts have a tree structure in which contexts may themselves contain nested contexts and the structure generally mirrors that of the views in the BUI.

Root Context

The initial context upon login is the root context, and serves as the parent or ancestor of all contexts. To navigate to a context, execute the name of the context as a command. For example, the functionality available in the Chapter 4, Network Configuration view in the browser is available in the configuration context of the CLI. From the root context, this can be accessed by typing it directly:

dory:> configuration

Note that the prompt changes to reflect the context, with the context provided between the colon and the greater-than sign in the prompt.

Child Contexts

The show command shows child contexts. For example, from the configuration context:

dory:configuration> show
                             net => Configure networking
                        services => Configure services
                         version => Display system version
                           users => Configure administrative users
                           roles => Configure administrative roles
                     preferences => Configure user preferences
                          alerts => Configure alerts
                         storage => Configure Storage

These child contexts correspond to the views available under the Chapter 6, Storage Area Network Configuration view in the browser, including Chapter 4, Network Configuration, Chapter 11, ZFSSA Services and Chapter 7, User Configuration, PreferencesChapter 8, Setting ZFSSA Preferences and so on. To select one of these child contexts, type its name:

dory:configuration> preferences 
dory:configuration preferences> 

Navigate to a descendant context directly from an ancestor by specifying the intermediate contexts separated with spaces. For example, to navigate directly to configuration preferences from the root context, simply type it:

dory:> configuration preferences
dory:configuration preferences>

Dynamic Child Contexts

Some child contexts are dynamic in that they correspond not to fixed views in the browser, but rather to dynamic entities that have been created by either the user or the system. To navigate to these contexts, use the select command, followed by the name of the dynamic context. The names of the dynamic contexts contained within a given context are shown using the list command. For example, the users context is a static context, but each user is its own dynamic context.

dory:> configuration users
dory:configuration users> list 
NAME                     USERNAME                 UID        TYPE
John Doe                 bmc                      12345      Dir
Super-User               root                     0          Loc

To select the user named bmc, issue the command select bmc:

dory:configuration users> select bmc 
dory:configuration users bmc> 

Alternately, select and destroy can in some contexts be used to select an entity based on its properties. For example, one could select log entries issued by the reboot module in the maintenance logs system context by issuing the following command:

dory:maintenance logs system> select module=reboot 
dory:maintenance logs system entry-034> show
  timestamp = 2010-8-14 06:24:41
     module = reboot
   priority = crit
       text = initiated by root on /dev/console syslogd: going down on signal 15

As with other commands, select may be appended to a context-changing command. For example, to select the user named bmc from the root context:

dory:> configuration users select bmc 
dory:configuration users bmc>

Last Context

Use the last command to navigate to a previously selected or created context. This command is presently implemented in only the replication action context.

The following example creates a replication action, and then uses the last and get id commands to retrieve the replication action ID. Then a different action is selected, and the last and get id commands are used to retrieve the ID of the last-visited replication action.

dory:shares p1/share replication> list
           TARGET          STATUS     NEXT
action-000  oakmeal         idle       Sync now
action-001  dory            idle       Sync now
dory:shares p1/share replication> create
dory:shares p1/share action (uncommitted)> set target=dory
                       target = dory (uncommitted)
dory:shares p1/share action (uncommitted)> set pool=p0
                         pool = p0 (uncommitted)
dory:shares p1/share action (uncommitted)> commit
dory:shares p1/share replication> last
dory:shares p1/share action-002> get id
                           id = 7034367a-d4d8-e26f-fa93-c3b454e3b595
dory:shares p1/share action-002> done
dory:shares p1/share replication> select action-000
dory:shares p1/share action-000> get id
                           id = 9895d9f4-7b23-ebe1-faf2-d85a581e3dff
dory:shares p1/share action-000> done
dory:shares p1/share replication> last get id
                           id = 9895d9f4-7b23-ebe1-faf2-d85a581e3dff
dory:shares p1/share replication>