APIs in Category: lun | API version 3.6R2

lun-list-info-iter-end lun-list-info-iter-next lun-list-info-iter-start | DFM tracks all the luns it discovers on filers it is monitoring. These APIs give the user access to the information DFM has collected about luns.

NetApp Manage ONTAP

lun-list-info-iter-end | [top]

> The lun-list-info-iter-* set of APIs are used to retrieve the list of luns. lun-list-info-iter-end is used to tell the DFM station that the temporary store used by DFM to support the lun-list-info-iter-next API for the particular tag is no longer necessary.

> Input Name | Range | Type | Description
> tag |  | string | An internal opaque handle used by the DFM station

> Errno | Description
> EINVALIDTAG |  |

lun-list-info-iter-next | [top]

> For more documentation please check lun-list-info-iter-start. The lun-list-info-iter-next API is used to iterate over the members of the luns stored in the temporary store created by the lun-list-info-iter-start API.

> Input Name | Range | Type | Description
> maximum |  | integer | The maximum number of entries to retrieve. Range: [1..2^31-1]
> tag |  | string | Tag from a previous lun-list-info-iter-start. It's an opaque handle used by the DFM station to identify the temporary store created by lun-list-info-iter-start.
> Output Name | Range | Type | Description
> luns |  | lun-info[] | List of luns.
> records |  | integer | The number of records actually returned. Range: [1..2^31-1]

> Errno | Description
> EINVALIDINPUTERROR |  |
> EINVALIDTAG |  |

lun-list-info-iter-start | [top]

> The lun-list-info-iter-* set of APIs are used to retrieve the list of luns in DFM. lun-list-info-iter-start returns the union of lun objects specified, intersected with rbac-operation. It loads the list of luns into a temporary store. The API returns a tag that identifies that temporary store so that subsequent APIs can be used to iterate over the luns in the temporary store. If lun-list-info-iter-start is invoked twice, then two distinct temporary stores are created.

> Input Name | Range | Type | Description
> object-name-or-id |  | obj-name-or-id optional | Name or identifier of an object to list luns for. The allowed object types for this argument are: Resource Group Host Aggregate Volume Qtree Lun If object-name-or-id identifies a lun, that single lun will be returned. If object-name-or-id resolves to more than one lun, all of them will be returned. If no object-name-or-id is provided, all luns will be listed.
> rbac-operation |  | string optional | Name of an RBAC operation. If specified, only return luns for which authenticated admin has the required capability. A capability is an operation/resource pair. The resource is a lun or a container with one or more luns in it. The possible values that can be specified for operation can be obtained by calling rbac-operation-info-list. If operation is not specified, then it defaults to DFM.Database.Read. For more information about operations, capabilities and user roles, see the RBAC APIs.
> Output Name | Range | Type | Description
> records |  | integer | Number which tells you how many items have been saved for future retrieval with lun-list-info-iter-next. Range: [1..2^31-1]
> tag |  | string | Tag to be used in subsequent calls to lun-list-info-iter-next. It is an opaque handle used by the DFM station to identify a temporary store.

> Errno | Description
> EINTERNALERROR |  |
> EAPIERROR |  |
> EACCESSDENIED |  |
> EOBJECTNOTFOUNDERROR |  |
> EOBJECTAMBIGUOUS |  |
> EDATABASEERROR |  |
> EINVALIDINPUTERROR |  |

Element definition: lun-info | [top]

> Information about a lun.

> Name | Range | Type | Description
> host-id |  | obj-id | Identifier of host on which the lun resides. Always present in the output.
> host-name |  | obj-name | Name of host on which the lun resides. Always present in the output. The name is any simple name such as myhost.
> lun-id |  | obj-id | Identifier of the lun.
> lun-path |  | obj-name | Path name of the lun including the volume or qtree where the lun exists. The name will be similar to myvol/mylun or myvol/myqtree/mylun.
> lun-size |  | integer | Lun size in bytes. Range : [0..2^64-1].
> object-perf-status |  | obj-status optional | Current status of the lun based on performance events
> object-status |  | obj-status optional | Current status of the lun based on all events
> qtree-id |  | obj-id optional | Identifier of qtree on which the lun resides. Present in the output only if the lun resides on a qtree.
> qtree-name |  | obj-name optional | Name of qtree on which the lun resides. Present in the output only if the lun resides on a qtree. The name is any simple name such as myqtree.
> volume-id |  | obj-id | Identifier of volume on which the lun resides. Always present in the output.
> volume-name |  | obj-name optional | Name of volume on which the lun resides. The name is any simple name such as myvol. volume-name is not returned if the lun belongs to a qtree on a vfiler and the authenticated admin does not have the required capability. For details of the required capability, see description of rbac-operation input element in lun-list-info-iter-start api.

Element definition: obj-name-or-id | [top]

> Name or internal ID of a DFM object. This typedef is an alias for the builtin ZAPI type string. An obj-name-or-id must contain between 1 and 64 characters, and must conform to one of the following formats: It must have the format of an obj-name, or It must be the decimal numeric string form of a positive integer whose value is in the range [1..2^31 - 1]. Elements of type obj-name-or-id are used only as inputs to ZAPIs. The value must match either the name or internal ID of an existing DFM object. The ZAPI must specify the object's DFM object type (e.g. data set, host, DP policy, etc.). Some ZAPIs allow the object to be one of several different types. If the format of an obj-name-or-id input element does not conform, or the value does not match the name or ID of an existing object, then generally the ZAPI documents that it fails with error code EOBJECTNOTFOUND. A ZAPI may return more specific error codes. In such cases, the ZAPI specification must document its behavior. If a ZAPI can accept a null value (e.g. reference to no object at all) for such an element, then the element is declared optional, and the absence of the input element represents a null value.

> [none]

Element definition: obj-id | [top]

> Identification number (ID) for a DFM object. This typedef is an alias for the builtin ZAPI type integer. Object IDs are unsigned integers in the range [1..2^31 - 1]. In some contexts, an object ID is also allowed to be 0, which is interpreted as a null value, e.g., a reference to no object at all. The ID for a DFM object is always assigned by the system; the user is never allowed to assign an ID to an object. Therefore, an input element of type obj-id is always used to refer to an existing object by its ID. The ZAPI must specify the object's DFM object type (e.g. data set, host, DP policy, etc.). Some ZAPIs allow the object to be one of several different types. If the value of an obj-id input element does not match the ID of any existing DFM object of the specified type or types, then typically the ZAPI fails with error code EOBJECTNOTFOUND. A ZAPI may deviate from this general rule, for example, it may return a more specific error code. In either case, the ZAPI specification must document its behavior.

> [none]

Element definition: obj-name | [top]

> Name of a DFM object. This typedef is an alias for the builtin ZAPI type string. An object name must conform to the following format: It must contain between 1 and 64 characters. It may start with any character and may contain any combination of characters, except that it may not consist solely of decimal digits ('0' through '9'). In some contexts, a name may be the empty string (""), which is interpreted as a null value, e.g., a reference to no object at all. The behavior of a ZAPI when it encounters an error involving an obj-name input element depends on how the ZAPI uses the input element. Here are the general rules: If the input name element is used to create a new object with the given name, or rename an existing object to that name, and the name does not conform to the above format, then the ZAPI fails with error code EINVALIDINPUTERROR. Note that because EINVALIDINPUTERROR is such a common error code, ZAPI specifications are not required to document cases when they may return it. If the input name element is used to refer to an existing object with that name, and there is no object with that name, then the ZAPI fails with error code EOBJECTNOTFOUND. Generally the ZAPI specification documents cases when it may return this error code. A ZAPI may deviate from these general rules, for example, it may return more specific error codes. In such cases, the ZAPI specification must document its behavior. If an input name element is used to refer to an existing object, then the ZAPI specification must specify which DFM object type (e.g. data set, host, DP policy, etc.) is allowed. Some ZAPIs allow the object to be one of several different types. See the description of obj-full-name for examples of valid input formats. Note that there is no requirement that all object names must be unique. However, the names for some specific types of objects are constrained such that no two objects of that type may have the same name. For example, this constraint applies to data sets, DP schedules, and DP policies. This means that no two data sets may have the same name, but a data set may have the same name as a DP schedule or DP policy. In general, object names are compared in a case-insensitive manner. This means that, for example, "MyObject" and "MYOBJECT" are considered to be the same name for purposes of: creating new objects, renaming existing objects, or looking up an object by name. On the other hand, ZAPIs that return an obj-name generally do not change the capitalization at all. For example, if an object's name has been set to "MyObject", then list iteration ZAPIs that return the object's name return it as "MyObject" rather than "MYOBJECT" or "myobject". ZAPIs that operate on obj-name values and do not follow these general rules about case sensitivity must document the rules that they do follow. One important exception to these general rules is that volumes, qtrees, OSSV directories, SRM paths, interfaces, FCP targets and FC switch ports all have case-sensitive names. When looking up objects of these types by name, the case must match the object name.

> [none]

Element definition: obj-status | [top]

> A status value which can be associated with a DFM object. This typedef is an alias for the builtin ZAPI type string. The severity associated with an event has this type. Possible values are: 'unknown', 'normal', 'information', 'unmanaged' 'warning', 'error', 'critical', 'emergency'. unknown: An object has an unknown status when it transitions from one state to another. Ideally, an object will have this status briefly. For example, when an object has been added, but not yet discovered. normal: An object has normal status when it is working within the thresholds specified in DFM. information: The information events are normal occurrences on an object for which you can define alarms. unmanaged: An object is considered to be unmanaged when the login and password are not set for the appliance or agent. warning: An object has the warning status when an event related to the object occurred that an administrator should know about. The event will not cause service disruption. error: An object has error status when it does not cause any service disruption, but it may affect performance. critical: An object has critical status when it is still performing, but service disruption may occur if corrective action is not taken immediately. emergency: An object is in emergency status when it stops performing unexpectedly and could lose data. In some contexts, it is important that severities are ordered (as above). For example, an alarm might be triggered if an event with a given severity "or worse" occurs. In this example, worse means "after" in the list above.

> [none]