snapdrive

NAME

snapdrive − tool to simplify snapshot management and storage provisioning

SYNOPSIS

NOTE: -devicetype shared may not be used with -igroup and -nolvm option. In Snapdrive for UNIX 2.2, this option is enabled only on Solaris 9, with VERITAS SFRAC 4.1 on fcp only. snapdrive snap [operation [options ...] ]

snapdrive snap { show | list } -filer filername [filername...] [-verbose] snapdrive snap { show | list } -filervol filervol [filervol...] [-verbose] snapdrive snap { show | list } { -lun | -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [-verbose] snapdrive snap { show | list } [-snapname] long_snap_name [snap_name ...] [-verbose] snapdrive snap create { -lun | -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [ { -lun | -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec...]] -snapname snap_name [-force [-noprompt]] [-nofilerfence] [-unrelated] snapdrive snap delete [-snapname] long_snap_name [snap_name ...] [-verbose] [-force [-noprompt]] snapdrive snap rename [-snapname] old_long_snap_name new_snap_name [-force [-noprompt]] snapdrive snap connect -lun s_lun_name d_lun_name [[-lun] s_lun_name d_lun_name ...] -snapname long_snap_name [-igroup ig_name [ig_name ...]] [-devicetype {shared | dedicated}] snapdrive snap connect fspec_set [fspec_set...] -snapname long_snap_name [-igroup ig_name [ig_name ...]] [-autoexpand] [-autorename] [-nopersist] [{-reserve | -noreserve}] [-readonly] [-devicetype {shared | dedicated}] snapdrive snap disconnect -lun long_lun_name [lun_name ...] [-devicetype {shared | dedicated}] snapdrive snap disconnect { -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [{ -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] ...] [-full][-devicetype {shared | dedicated}] snapdrive snap restore -snapname snap_name { -lun | -vg | -dg | -fs | -lvol | -hostvol | -file } file_spec [file_spec ...] [{ -lun | -vg | -dg | -fs | -lvol | -hostvol | -file } file_spec [file_spec ...] ...] [-force [-noprompt]] [{-reserve | -noreserve}][-devicetype {shared | dedicated}]

snapdrive storage [operation [options ...] ]

snapdrive storage { show | list } -filer filer_name [filer_name ...] [-verbose] [-quiet] [-devicetype {shared | dedicated}] snapdrive storage { show | list } -filervol long_filer_path [filer_path ...] [-verbose] [-quiet] [-devicetype {shared | dedicated}] snapdrive storage { show | list } -lun long_lun_name [lun_name ...] [-verbose] [-quiet] [-devicetype {shared | dedicated}] snapdrive storage { show | list } { -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [{ -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...]] [-verbose] [-quiet] snapdrive storage { show | list } { -all | -devices } [-devicetype {shared | dedicated}] snapdrive storage create -lun long_lun_name [lun_name ...] -lunsize size [{ -dg | -vg } dg_name] [-igroup ig_name [ig_name ...]] [{ -reserve | -noreserve }][-devicetype {shared | dedicated}] snapdrive storage create -fs file_spec -nolvm [-fstype type] [-fsopts options] [-mntopts options] [-nopersist] { -lun long_lun_name | -filervol long_filer_path } -lunsize size [-igroup ig_name [ig_name ...]] [{ -reserve | -noreserve }][-devicetype {shared | dedicated}] snapdrive storage create host_lvm_fspec -filervol long_filer_path -dgsize size [-igroup ig_name [ig_name ...]] [{ -reserve | -noreserve }][-devicetype {shared | dedicated}] snapdrive storage create host_lvm_fspec -lun long_lun_name [lun_name ...] -lunsize size [-igroup ig_name [ig_name ...]] [{ -reserve | -noreserve }][-devicetype {shared | dedicated}] snapdrive storage delete -lun long_lun_name [lun_name ...][-devicetype {shared | dedicated}] snapdrive storage delete { -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [{ -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] ...] [-full][-devicetype {shared | dedicated}] snapdrive storage resize { -vg | -dg } file_spec { -growby | -growto } size [-addlun [-igroup ig_name [ig_name ...]] [{-reserve | -noreserve}]] snapdrive storage connect -lun long_lun_name [lun_name ...] [-igroup ig_name [ig_name ...]][-devicetype {shared | dedicated}] snapdrive storage connect -fs file_spec -nolvm -lun long_lun_name [-igroup ig_name [ig_name ...]] [-nopersist] [-mntopts options][-devicetype {shared | dedicated}] snapdrive storage connect -fs file_spec { -hostvol | -lvol } file_spec -lun long_lun_name [lun_name ...] [-igroup ig_name [ig_name ...]] [-nopersist] [-nopersist] [-mntopts options][-devicetype {shared | dedicated}] snapdrive storage disconnect -lun long_lun_name [lun_name...][-devicetype {shared | dedicated}] snapdrive storage disconnect { -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [{ -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] ...] [-full][-devicetype {shared | dedicated}]

snapdrive host [operation [options ...] ]

snapdrive host connect -lun long_lun_name [lun_name ...] snapdrive host connect -fs file_spec -nolvm -lun long_lun_name [-nopersist] [-mntopts options] snapdrive host connect -fs file_spec { -hostvol | -lvol } file_spec -lun long_lun_name [lun_name ...] [-nopersist] [-mntopts options] snapdrive host disconnect -lun long_lun_name [lun_name...] snapdrive host disconnect { -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [{ -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] ...] [-full]

snapdrive version snapdrive config [operation [options ...] ]

snapdrive config access { show | list } filername snapdrive config set user_name filername [filername ...] snapdrive config delete filername [filername ...] snapdrive config list snapdrive config prepare luns -count count [-devicetype {shared | dedicated}] snapdrive config check cluster

DESCRIPTION

The tool snapdrive manages snapshots and storage provisioning via a command-line interface. Each command line specifies a single operation. A command line consists of a command name and an operation name, usually followed by options and one or more keywords naming entities to be operated on. These entities include filers, filer volumes, filer-resident LUNs, and host-side LVM entities -- file systems, logical (or host) volumes, and volume (or disk) groups. The snapdrive command set supports snapshot management (snap command) and storage provisioning (storage and host commands). In addition, the config command can be used to monitor or control some of snapdrive’s configuration details. snapdrive provides easy management of the entire storage hierarchy, from the host-side application-visible file down through the volume manager to the filer-side LUNs providing the actual repository. Some examples of this hierarchy, in order of increasing complexity, are: File -> Raw Disk -> LUN(s) File -> File System -> Raw Disk -> LUN(s) File -> File System -> Host Volume -> Disk Group -> Raw Disk -> LUN(s) SnapDrive supports creating and restoring snapshots of disk groups, as well as connecting existing snapshots at a new location. Requests for snapshots of file systems and/or host volumes will result in all the disk groups containing the file systems and host volumes being made consistent (freezing file systems), and a snapshot being taken. Restoring a snapshot of a disk group entails restoring all the LUNs in that disk group. This means that two host volumes in the same disk group will always be restored together. Quiescing an application that is running against raw host volumes cannot be accomplished using SnapDrive. However, a script that places a database into hot backup mode can invoke the snapdrive CLI to create a snapshot. In addition, SnapDrive eases the administration of LUNs on the filer, and of LVM-based entities on the host, such as disk groups, logical volumes and file systems. Supported operations include creating, destroying and resizing these entities. SnapDrive also simplifies connecting to existing filer LUNs. SnapDrive can operate on several varieties of host-visible storage:

	o	filer-based LUNs
	o	host LVM entities (volume groups, logical volumes and file systems)
	o	file systems constructed directly in a filer LUN, with no host LVM infrastructure
	o	raw LUNs, as connected to the local host, also containing no host LVM superstructure
	o	filer directory trees mounted via NFS

SUPPORTED PLATFORMS

For SnapDrive 2.2, supported platforms are:

SOLARIS

On Solaris 8, 9 and 10, Veritas Volume Manager 3.5 or 4.0 or 4.1, multipathing VxDMP, and VxFS file system, with Fibre Channel (FCP). On Solaris 9 and 10 update 1, UFS file system, with Hardware iSCSI. On Solaris 10 update 1, multipathing MPxIO, and UFS file system, with Software iSCSI.

HPUX

On HPUX 11i, the native Logical Volume Manager LVM, native multipathing PVLinks, and VxFS file system, with both Fibre Channel (FCP) and iSCSI. (On HPUX, VxFS is also known as JFS.)

AIX

On AIX 5.1, 5.2 and 5.3, the native Logical Volume Manager LVM, multipathing SANPath, and native file systems JFS and JFS2, with both Fibre Channel (FCP) and iSCSI.

LINUX

On Red Hat Enterprise Linux 3.0 (Update 4) (32 and 64 bit), Red Hat Enterprise Linux 4.0 (Update 2) (32 and 64 bit), SUSE Linux Enterprise Server 9 (SP 3) (32 and 64 bit) the Sistina LVM, no multipathing, and ext3 file system, with both Fibre Channel (FCP) and iSCSI. Specific limitations for SnapDrive operations are noted in the description of each operation.

OPTIONS

snapdrive commands consist of the command name followed by the operation desired, then by any options and their arguments. Except for a few single-letter shortcuts (noted below), only full-word options are supported; each must be introduced by a leading hyphen (dash) and they may not be concatenated even in the few cases that have a single-letter alias. snapdrive commands use file_spec options, or keywords, to introduce and indicate the type of sequences of strings that name host and filer entities to be created and manipulated. These sequence-initiating keywords begin with a hyphen and their meanings are:

	-fs		file system on the host, named via its mount point. For example: -fs /mnt/myfs1
	-lvol		logical volume name, including the volume group containing it. For example: -lvol large_vg/accounting_lvol
	-hostvol		host volume name, including the diskgroup containing it, an alias for -lvol (and its volume group). For example: -hostvol large_vg/accounting_lvol
	-vg		host volume group name. For example: -vg large_vg
	-dg		host disk group name (synonym for -vg). For example: -dg large_vg
	-lun		filer LUN name, which may include the names of the containing filer and filer volume (e.g., filer1:/vol/vol1/lunC), the name of a filer volume only (e.g., /vol/vol1/lunC), or simply the relative pathname of the LUN within its volume (e.g., lunC). Note that the relative pathname of a LUN may not contain a colon.
	-filervol		filer volume name, including the colon-separated name of the containing filer (e.g., filer1:/vol/vol1)
	-filer		filer name
	-snapname		snapshot name, perhaps including the colon-separated names of the associated filer and volume (e.g., filer1:/vol/vol1:snap1). Note that the short form of a snapshot name (i.e., the name following the volume name) may not contain a colon.
	-igroup		one or more existing filer igroups to be used to map newly-created or newly-connected LUNs
	-file		one or more absolute pathnames, each used to indicate an individual file to be restored from the snapshot of an NFS-mounted directory tree

Other snapdrive options, which also begin with a hyphen (dash), provide for other types of parameters:

	-help (or -h)		prints out the usage message for this command and operation. All commands and operations handle this option, which should be used alone, not combined with other options.
	-verbose (or -v)		enables more detailed output, where appropriate. All commands and operations accept this option, though some may ignore it.
	-quiet (or -q)		suppress reporting of errors and warnings, returning only zero (success) or non-zero status. All commands and operations accept this option, which is useful for avoiding chatty output when scripting. In the case of the storage show, snap show and the config show commands, the quiet option will be ignored completely. Scripts can use the snapdrive exit status to determine whether the operation was successful. The -quiet option overrides -verbose.
	-force (or -f)		attempt operations that might have dangerous or non-intuitive side effects, and that ordinarily would be disallowed.
	-full		attempt operations invoked using a non-empty host-side entity (e.g., a disk group that contains one or more logical volumes).
	-noprompt		ensure that no prompting occurs during command execution; by default, operations that might have dangerous or non-intuitive side effects will cause the user to be prompted to confirm that the operations should be attempted.
	-dgsize size		usable size of a disk group to be created, in host object bytes
	-vgsize size		usable size of a disk group to be created, in host object bytes (synonym for -dgsize)
	-lunsize size		size of filer LUN in bytes
	-growby size		number of bytes to add to LUN, disk group, or volume
	-growto size		target size in bytes for growth of a LUN, disk group, or volume
	-fstype type		type of a file system to be created, where type must refer to a file system type supported by the current host. Supported types are: VxFS (for Solaris and HP-UX), JFS or JFS2 (for AIX), or ext3 (for Linux). Case does not matter in naming the type -- for instance, vxfs is synonymous with VxFS.
	-fsopts type		options to be passed to the operation that creates a new file system
	-mntopts type		specify filesystem-specific options to be passed to whatever host operation mounts a new file system (i.e., the mount command). Normally, the argument given to this option will be a comma-separated list of option names. This list will be passed as appropriate to the host mount operation, and will be inserted verbatim in any line added to the host mount table file ("fstab" file) as a result of the operation.
	-addlun		add a new, internally-generated LUN to a storage entity given to the storage resize operation, in order to increase its size.
	-autoexpand		for the snap connect operation, allow a subset of the contents of a disk group to refer to that disk group on the command line.
	-autorename		for the snap connect operation, rename destination entities as needed to avoid naming conflicts.
	-nolvm		create or connect to any file system involved in the current operation directly inside a filer LUN, without any LVM infrastructure.
	-nopersist		suppress any update to the host mount table file ("fstab" file) resulting from mounting a file system.
	-noreserve		create any LUNs resulting from an operation with space reservation disabled.
	-reserve		create any LUNs resulting from an operation with space reservation enabled.
	-nofilerfence		suppress the use of the data ontap consistency group feature in creating snapshots that span multiple filer volumes. this feature, available in data ontap starting with release 7.2, suspends access to an entire filer volume. The option causes snapdrive to freeze access to individual LUNs instead.
	-readonly		for an NFS directory tree, indicate that snap connect will connect to the original, snapshot-resident instance of the tree, rather than creating and connecting a copy of the tree.
	-unrelated		indicate that multiple file_specs given to snap create are unrelated to one another, hence that the snapshot does not need to be consistent across all of the file_specs. (The snapshot of each file_spec will still be consistent with respect to that individual file_spec, however.)
	-all		request that storage show display the host devices and LVM entities corresponding to all connected filer LUNs.
	-devices (or -dev)		request that storage show display the host devices corresponding to all connected filer LUNs.
	-devicetype		request to perform operations on cluster-wide (shared) or dedicated system.

Some snapdrive commands use the -dgsize or -lunsize options to specify a size in bytes. The size may also be given as a signed number followed by a case insensitive letter indicating the units: k kilobytes (2^10 bytes) m megabytes (2^20 bytes) g gigabytes (2^30 bytes) t terabytes (2^40 bytes) For example, "-size 1024m" is equivalent to "-size 1G". The object-specifying keywords outlined above introduce the targets of snapdrive operations, and take arguments specifying one or more targets. None of these arguments may begin with a hyphen (dash). The usage and syntax synopsis lines use the following conventions to illustrate what those arguments mean:

	file_spec		indicates an object of which snapdrive can create a snapshot -- a host volume, disk group, filer LUN, or file system.
	src_fspec		a file_spec naming an entity within the source snapshot for an operation.
	dest_fspec		a file_spec naming an entity within the destination snapshot for an operation.
	long_snap_name		a long-form name indicating a snapshot, including the filer name, volume, and snapshot name, separated by colons. (Hence a colon may not be included in the snapshot name.) For example: big_filer:/vol/account_vol:snap_20031115
	short_snap_name		a short-form snapshot name, for use when the filer and filer volume are not necessary. For example, in creating a snapshot, the filer and volume must be the same as those of the original data.
	snap_name		a snapshot name, long or short form.
	long_filer_path		a long-form pathname which provides the filer name, volume name, and possibly other directory and file elements within that volume. Examples are: our_filer:/vol/vol3/qtree_2 or 10.10.10.1:/vol/vol4/lun_21
	filer_path		a pathname corresponding to a filer object, which may or may not contain the filer name and volume. Examples are: our_filer:/vol/vol3/qtree_2 or /vol/vol3/qtree_2 or just qtree_2
	long_lun_path		a long_filer_path that designates a LUN on the filer.
	lun_path		a filer_path that designates a LUN on the filer.
	host_device_path		a pathname that indicates a host system device, such as /dev/rsdk/c0t6d0s7
	host_path		a pathname indicating a file, device, or directory on the host
	path		any pathname

Initiator Groups

Any snapdrive operation that creates or connects to LUNs on the filer has to arrange for the LUNs to be mapped to the host via an initiator group, or igroup. By default, snapdrive will create and use igroups without any user intervention. It is strongly recommended that users not change this behavior. However, in special cases you can use the -igroup option to specify one or more existing igroups on the filer where the LUNs are to be created. Because it cannot always determine what initiators are available on the current host, snapdrive does not validate the contents of any igroups specified. The igroups given may contain initiators that snapdrive could find on the current host, initiators not found there, or any combination of the two. Note that, if you specify an igroup explicitly in creating storage, you should be sure that the named igroup is compatible with how you intend to use the associated LUNs in the future. Specifically:

	o	LUNs accessed by storage delete or snap disconnect must be mapped using igroups that contain only initiators found on the local host, or the operation will fail. Since both of these operations delete filer LUNs, they will not be attempted on a LUN that is mapped by an igroup containing initiators not found on the local host.
	o	LUNs accessed by storage disconnect must not be mapped using igroups that contain a mixture of initiators found on the local host and other initiators, or the operation will fail. LUNs are removed successfully from igroups that contain only initiators found on the local host. LUN mappings in igroups that contain only initiators not found on the local host are ignored.

When -igroup is not given in creating filer LUNs, snapdrive will use an igroup with a name of the form hostname_proto_SbIg, where hostname is the local (non-domain qualified) name of the host, and proto is either fcp or iscsi. All initiators found on the local host for the applicable protocol will be placed in the igroup. If no igroup exists with this name, one will be created. If an igroup exists with this name, but with the incorrect contents, it will be ignored, and a new igroup name will be tried. The new igroup name has the same format as above, but with a number uniq inserted to make it unique. The format of the new name is hostname-uniq_proto_SbIg. These internally-generated igroups are "garbage-collected" as storage is deleted or disconnected from the local host. If, as LUNs are removed from an internal igroup, the igroup eventually maps no LUNs, the igroup will be deleted. An igroup is considered internal (or not) based on its name.

Internally-Generated Names

In creating storage, users sometimes will not want to specify all of the names for host LVM entities or filer LUNs that are required in order to complete an operation. For instance, in creating a file system, snapdrive needs names for a file system mount point, a logical volume, a volume group, and at least one filer LUN. If all of these are to be created from scratch, it is a major convenience not to have to provide names for all four entities. If the user omits a needed name, snapdrive will derive the name internally. For storage create and storage resize, the names are based on the "lowest-level" name that the user did specify, one of:

	o	a volume group name (if either a volume group or a logical volume was named) or
	o	the rightmost directory in a file system mount point (if no volume group or logical volume was named).

Note that a volume group name is used when a logical volume is named because a volume group always has to be included in a logical volume name. To the user-specified name, snapdrive adds a suffix, one of:

	_SdDg		for a volume group
	_SdHv		for a logical volume
	_SdLun		for a filer LUN

If the resulting name is already in use, snapdrive will add a number to it to produce a unique, unused name. The number, preceded by a hyphen, will follow the user-specified part of the name. A naming conflict for one of the internal names needed by an operation will cause a new value to be generated for that name only. So for example the command line: # snapdrive storage create \ -fs /mnt/myfs -filervol toaster:/vol/vol0 -dgsize 100m would result in the initial set of internal names myfs_SdDg, myfs_SdHv and myfs_SdLun. If any of these names were unusable, then a new value would be calculated for the affected names. So for instance if myfs_SdDg were unavailable, the value myfs-1_SdDg would be tried instead, then myfs-2_SdDg and so on. The snap connect operation can also result in internally-generated names. For this operation, the rules are somewhat different. Here, the goal is to generate names for the copies of filer LUNs created by the operation, and for the host LVM entities created using the copied LUNs. These entities are called "destination" entities. Generated names for snap connect are based on a source name to which a "snapshot volume group suffix" may be added. This suffix consists of an underscore followed by a number that makes the suffixed name unique. The suffix is assigned per volume group and per snapshot. LUNs and LVM entities from different groups (even different groups within the same snapshot) may have different suffixes assigned. For newly-created (copied) LUNs, names are always generated, even if -autorename is not specified. The source for the new name is the name of the LUN being copied. For example, the first copy of LUN myfs_SdLun would be called myfs_SdLun_0. For host LVM entities, an internal name is generated only if -autorename is given and if a destination name is not specified on the command line. No destination name specified on the command line is ever replaced by another name. When there is a source file_spec that corresponds to the destination, its name becomes the source for the new name. When there is no source file_spec (that is, when an operation is undertaken because of -autoexpand), the source name comes from data recorded as part of the snapshot. A suffix may be added to the source name based on the suffix used for the LUNs that underlie the LVM entity. The exact names used for the host-side entities in a given fspec_set are determined as follows:

	o	If all of the source names in the fspec_set are usable as destination names, then the source names are used unmodified.
	o	If any of the source names is not usable as a destination name, then all of the names are modified with the snapshot volume group suffix of the underlying LUN. For example, consider the source volume group name myvg. If the corresponding destination volume group used the copied LUN myfs_SdLun_0, the first modified name used for the volume group would be myvg_0.
	o	If after following the procedure in the previous bullet, any of the modified names are not usable, then that name alone is further modified by adding a number to make the name unique, exactly as described for storage create. So if the destination name myvg_0 were already in use, snapdrive would next try myvg-1_0, then myvg-2_0 and so on.

For all uses of generated names, snapdrive must cope with per-platform limits on acceptable name lengths, which may be as short as 15 characters. Where these limits come into play, as much as possible of a source or user-specified name is preserved in deriving a generated name, but will still be overwritten if need be to add the required suffix for the generated name.

Snapshot Management

The snapdrive snapshot management operations are all of the form

snapdrive snap [operation [options ...] ]

where operation is one of show, list, create, delete, rename, restore, connect or disconnect. snapdrive snap { show | list } -filer filername [filername...] [-verbose] snapdrive snap { show | list } -filervol filervol [filervol...] [-verbose] snapdrive snap { show | list } { -lun | -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [-verbose] snapdrive snap { show | list } [-snapname] long_snap_name [snap_name ...] [-verbose] The first two forms display the snapshots available for the given filer(s) or filer volume(s). The third form will display the snapshots of the specified filer LUNs, disk groups, volume groups, file systems, or host volumes. The current host is assumed. The named host-side entities are translated to their underlying filer volumes, and the operation then searches the volumes for snapshots of the host-side entities. You can change the function of the third form of this operation by specifying one of the filer-side options (-filer, -filervol or -snapname) in addition to the file_spec keyword. With this combination of arguments, the filer-side entity named will be searched directly for snapshots containing the named host-side entities. In this case, the host-side entities are not looked up on the host. Thus you can locate snapshots of an entity even when it does not exist on your host. The final form of this operation displays information about the snapshots listed. For all forms, the -verbose option displays more detailed information. Examples: # snapdrive snap show -v -filer filer2 # snapdrive snap show -v -filervol filer2:/vol/volacct # snapdrive snap show -v -lvol hplvol23 # snapdrive snap show -v -lvol hplvol23 -filer filer2 # snapdrive snap show -quiet -snapname filer3:/vol/vol2:snapA # snapdrive snap show -quiet filer3:/vol/vol2:snapA # snapdrive snap show -quiet filer3:/vol/vol2:snapA filer7:/vol/vol0/snap23 # snapdrive snap show -snapname filer3:/vol/vol2:snapA snapX snapY # snapdrive snap show -v -snapname filer3:/vol/vol2:snapA # snapdrive snap show -verbose filer3:/vol/vol2:snapA /vol/vol3:snapB snapC Release 2.2 limitations: only long-form snapshot names are accepted. By default, snap show will display the names of the disk groups whose data was made consistent and captured in the snapshot, as well as the date/time the snapshot was taken and the name of the host that took the snapshot. # snapdrive snap show comet:/vol/vol1:* snap name host date snapped -------------------------------------------------------------------------------- comet:/vol/vol1:dares_dg123 bush Mar 5 09:05 dg1 dg2 dg3 comet:/vol/vol1:hourly.0 non-snapdrive snapshot comet:/vol/vol1:hourly.1 non-snapdrive snapshot comet:/vol/vol1:dg1 bush Mar 4 19:33 dg1 comet:/vol/vol1:nightly.0 non-snapdrive snapshot comet:/vol/vol1:vit-dg2dg3c bush Mar 4 18:34 dg2 dg3 comet:/vol/vol1:dares1_dg1 bush Mar 4 15:48 dg1 comet:/vol/vol1:vit-dg2dg3b bush Mar 4 15:39 dg2 dg3 comet:/vol/vol1:vit-dg2dg3a bush Mar 4 15:39 dg2 dg3 comet:/vol/vol1:vit-dg2dg3 bush Mar 4 15:09 dg2 dg3 comet:/vol/vol1:vit-dg3 bush Mar 4 15:08 dg3 comet:/vol/vol1:hourly.2 non-snapdrive snapshot comet:/vol/vol1:hourly.3 non-snapdrive snapshot comet:/vol/vol1:dares_dg1 bush Mar 4 10:50 dg1 comet:/vol/vol1:hourly.4 non-snapdrive snapshot comet:/vol/vol1:hourly.5 non-snapdrive snapshot comet:/vol/vol1:nightly.1 non-snapdrive snapshot comet:/vol/vol1:dg11fs_snap bush Mar 3 15:30 dg11 comet:/vol/vol1:dg13hvols_snap bush Mar 3 15:29 dg13 comet:/vol/vol1:dg1_snap bush Mar 3 15:27 dg1 comet:/vol/vol1:dg2dg3-1 bush Mar 3 15:22 dg2 dg3 The -verbose option provides more detailed output: # snapdrive snap show comet:/vol/vol1:dg2dg3 -v snap name host date snapped -------------------------------------------------------------------------------- comet:/vol/vol1:dg2dg3-1 bush Mar 3 15:22 dg2 dg3 host OS: SunOS 5.9 Generic_112233-08 snapshot name: dg2dg3-1 Volume Manager: vxvm 3.5 disk group: dg2 host volume: vol1 host volume: vol2 host volume: vol3 file system: vol1 mountpoint: /mnt/qa/dg2/vol1 file system: vol3 mountpoint: /mnt/qa/dg2/vol3 lun path --------------------------------- comet:/vol/vol1/nate_bush_lun2 comet:/vol/vol1/nate_bush_lun3 Volume Manager: vxvm 3.5 disk group: dg3 host volume: vol1 host volume: vol2 host volume: vol3 host volume: vol4 host volume: vol5 file system: vol1 mountpoint: /mnt/qa/dg3/vol1 file system: vol3 mountpoint: /mnt/qa/dg3/vol3 file system: vol5 mountpoint: /mnt/qa/dg3/vol5 lun path --------------------------------- comet:/vol/vol1/nate_bush_lun4 comet:/vol/vol1/nate_bush_lun5 snapdrive snap create { -lun | -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [ { -lun | -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec...]] -snapname snap_name [-force [-noprompt]] [-nofilerfence] [-unrelated] The snap create operation creates a snapshot of one or more filer volumes. When more than one volume is involved, the volumes may reside on the same filer, or on different filers. The volumes to be snapshoted are not directly named on the command line. Instead, the target volumes are found by translating the file_spec arguments given. These arguments are translated into a set of disk groups on the host. Any file systems hosted on volumes in those disk groups are frozen. Then a snapshot is taken of the filer volumes containing one or more LUNs in those disk groups. The snap_name argument provides the name of the snapshot. An existing snapshot will not be overwritten unless the -force option is given. The file_spec parameter must be one of -lun, -vg, -dg, -fs, -lvol or -hostvol. It is an error to combine -lvol with -hostvol, or -vg with -dg. If -hostvol is used, it must specify both the requested volume and the disk group containing it, such as -hostvol dg3/acct_volume. Note that -fs can specify any of three different kinds of file system: one residing in a logical volume, one residing directly in a LUN, or an NFS-mounted directory tree. For this operation, NFS directory trees and other kinds of file_specs may be named on the same command line. If -force is given and an existing snapshot is to be overwritten, the user will be prompted to confirm that he wants the operation to proceed, unless -noprompt is also given. If both options appear together, then the overwriting will occur with no further ado. The -unrelated option indicates that multiple file_specs given to snap create are unrelated to one another, hence that the snapshot does not need to be consistent across all of the file_specs. (The snapshot of each file_spec will still be consistent with respect to that individual file_spec, however.) The -nofilerfence option disables the use of the consistency group feature available in Data ONTAP starting with release 7.2, to address cases where "filer fencing" is not desirable. This fencing involves suspending I/O to entire volumes. If a volume is shared between applications, the user may prefer to freeze access only to the LUNs underlying each named file_spec, so that access to other data on that volume is not affected. However, with filer fencing disabled snapdrive may fail to create a consistent snapshot (which is why using fencing is the default). Note that the use of the consistency group feature is required in order to create a snapshot that is consistent across an NFS-mounted directory tree and any other entity (including a second NFS tree). So if an NFS tree plus any other file_spec are named on a command line, either -unrelated must be given, or consistency groups must be available on all target filers (and of course -nofilerfence may not be used). Examples: # snapdrive snap create -hostvol dg3/myvolume -snapname MySnapShot -force # snapdrive snap create -fs /mnt/dir -snapname YourSnapShot # snapdrive snap create -vg volgrp1 -snapname ASnapShot # snapdrive snap create -dg dg1 dg2 -snapname HerSnapShot # snapdrive snap create -fs /mnt/acct1 -snapname MySnapShot -nofilerfence For a host called DBserver, a disk group dg1 has host volumes myvol1 and myvol2. Volume dg1/myvol2 contains a file system mounted on /fs2. The disk group dg1 has three luns in it: toaster:/vol/vol1/lun0, toaster:/vol/vol1/lun1, and toaster:/vol/vol1/lun2. The following commands are all valid, and will all backup the same data: # snapdrive snap create -fs /fs2 -snapname snap1 # snapdrive snap create -dg dg1 -snapname snap1 # snapdrive snap create -vg dg1 -snapname snap1 # snapdrive snap create -hostvol dg1/myvol1 -snapname snap1 # snapdrive snap create -lvol dg1/myvol2 -fs /fs2 -snapname snap1 The name toaster:/vol/vol1:snap1 will be used for the created snapshot. If the snapshot toaster:/vol/vol1:snap1 already exists, the snap create command will fail, unless the -force option is given, in which case the old snap1 will be deleted, and the new snapshot put in its place. Please note that if the old snapshot is in use, the snap create will still fail, even with -force given. All the LUNs in the disk groups to be snapshotted must be online and available at the time of snap create, or the snapshot will fail. IMPORTANT NOTE: Whenever you add or remove a host volume, add or remove a LUN, or resize host volumes or file systems, you should take a new snapshot. This ensures that you have a consistent copy of the newly-configured disk group to restore from when you need it. Release 2.2 limitations: Root disk group: For logical volume managers with a root disk group, snapdrive will fail snap create of the root disk group. Shared disk group: snapdrive will not snap create disk groups that are shared with a host cluster partner. (snapdrive cannot ensure that I/O is quiesced on the host partner.) Boot device, swap device: snapdrive will not take a snapshot of a boot or swap device, even if it is located on a filer LUN. snapdrive snap delete [-snapname] long_snap_name [snap_name ...] [-verbose] [-force [-noprompt]] The snap delete operation removes the indicated snapshots. If any subsequent snap_name parameters are short-form snapshot names, the filer (and filer volume, if not given) are presumed to be those last seen in the argument sequence (read left to right). The -verbose option will list precisely what is being deleted; i.e. it will fill in the missing filer and filer volume names as shown in the example below. By default, if any of the designated snapshots were not created by SnapDrive for Unix, or if any of them are in use, whether for SnapMirror replication or backing a cloned LUN, none of the named shotshots will be deleted, and an error will be returned. The -force option can be used to override this behavior. If -force is given, the user will be prompted to confirm that he wishes to delete each in-use or foreign snapshot, and the deletion will be attempted if the user agrees. If the -noprompt option is given together with -force, the operation will output a warning describing each in-use or foreign snapshot, but will delete each such snapshot with no further ado. Similarly, an attempt to remove a nonexistent snapshot will result in diagnostic output and a non-zero exit status, and no snapshot will be removed unless all snapshots named can be removed. Example: # snapdrive snap delete -v filer1:/vol/vol0/snap1 snap2 snap3 snapdrive: deleting filer1:/vol/vol0/snap1 filer1:/vol/vol0/snap2 filer1:/vol/vol0/snap3 snapdrive snap rename [-snapname] old_long_snap_name new_snap_name [-force [-noprompt]] The snap rename operation changes the name of the snapshot old_long_snap_name to new_snap_name. It is an error for new_snap_name to exist unless the -force option is given. When -force is given, it is an error if new_snap_name exists but cannot be forcibly deleted (see snap delete above). If -force appears and an existing snapshot is to be overwritten, this operation will prompt the user to confirm that the overwriting should occur, unless -noprompt is also given. If both options are given, the overwriting will occur with no further ado. Both old_long_snap_name and new_snap_name must be on the same filer volume, so new_snap_name would normally be given as a short-form snapshot name. If a long-form name is used, it is an error if the two names do not resolve to the same filer volume. Examples: # snapdrive snap rename -force filer1:/vol/vol1:oldsnap newsnapshot # snapdrive snap rename filer1:/vol/vol1:FridaySnap filer1:/vol/vol1:Snap040130 snapdrive snap connect -lun s_lun_name d_lun_name [[-lun] s_lun_name d_lun_name ...] -snapname long_snap_name [-igroup ig_name [ig_name ...]] [-devicetype {shared | dedicated}] snapdrive snap connect fspec_set [fspec_set...] -snapname long_snap_name [-igroup ig_name [ig_name ...]] [-autoexpand] [-autorename] [-nopersist] [{-reserve | -noreserve}] [-readonly] [-devicetype {shared | dedicated}] The snap connect operation will connect objects captured by a snapshot at a new location on a host and make them ready to use on that system. This operation can be used to perform backup of snapshot data to another medium, to perform maintenance on a disk group, or simply to allow access to the data without disrupting the original copy. The objects may be connected either on the same host where the original snapshot was taken (the originating-host case), or on a different host (the non-originating host case). Unlike snap restore, this operation does not replace the existing contents of the LUNs that make up the host entity with the snapshot contents. Instead, it clones a disk group captured in long_snap_name and connects (imports) it to the host as requested. This operation always connects the entirety of the target disk group. Like snap restore, this operation then attempts to re-activate all of the logical volumes in the target disk group, and to mount all file systems in those logical volumes. This operation takes either of two forms. The first form is used to connect individual filer LUNs, where each s_lun_name specifies a LUN that existed in the named snapshot, and the corresponding d_lun_name specifies the name at which that LUN will be connected. All LUN names given must be short-form names. In other words, the names must not include a filer name or filer volume name. However, the lun names can contain qtree name. Thus, the LUN names can be of the form lun or qtree/lun. Each LUN named is assumed to reside in the same filer volume as long_snap_name. The second form of this operation is based on the fspec_set. Each fspec_set on the command line specifies one of: an NFS-mounted directory tree, a file system residing directly in a LUN, or a host LVM entity. The format of an fspec_set is: { -vg | -dg | -fs | -lvol | -hostvol } src_fspec [dest_fspec] [{ -destdg | -destvg } dg_name] [{ -destlv | -desthv } lv_name] In other words, an fspec_set specifies one file_spec from the source disk group. Optionally, it also specifies names to be used in connecting that file_spec in the context of the new destination disk group. Each fspec_set given must begin with -dg, -vg, -lvol, -hostvol or -fs. Note that -fs can specify any of three different kinds of file system: one residing in a logical volume, one residing directly in a LUN, or an NFS-mounted directory tree. If one NFS directory tree is given, all file_specs given must name such trees. A dest_fspec is connected using snapshot data extracted from the corresponding src_fspec within the snapshot long_snap_name. In other words, the operation looks up each src_fspec in the filer snapshot named by long_snap_name, finds the containing disk group, then connects the LUNs composing the disk group within long_snap_name at a new location that permits creating dest_fspec as a duplicate of src_fspec. The four -destxx options can be used to specify names for destination disk groups or logical volumes, whenever these names are not specified by the original src_fspec/dest_fspec pair. For instance, since the -fs option names only a destination mount point, the -destdg or -destvg option can be used to specify the destination disk group to be used. If a name needed to connect a destination LVM entity is not explicitly specified in the associated fspec_set, then snap connect will try to re-use the applicable name from the source disk group. In particular, if dest_fspec is omitted, it will be taken to be identical to src_fspec. In all cases, the destination names that this operation attempts to use must not be in use already, or the operation will fail. The -nopersist option affects how a copy of a file system is made. With this option specified, no entry for the mounted file system is made in the host mount table file ("fstab" file). Otherwise, such an entry is made. The -reserve and -noreserve options affect whether copy LUNs created by snap connect have space reservation enabled. By default, they do not. For an NFS directory tree, the -readonly option suppresses the creation of a copy of the tree that would ordinarily occur, by enabling the original copy of the tree (the copy stored in long_snap_name) to be accessed directly for reading only. This option enables the operation to complete without the use of filer FlexClone technology, which is required to create a writeable copy of an NFS-mounted directory tree. The -autoexpand and -autorename options affect the execution of snap connect in two ways. The first effect concerns whether or not all storage in a source disk group must be mentioned on the command line in order for connecting the disk group to succeed. The second effect concerns how the operation chooses destination names for host LVM entities for which no destination name is explicitly provided. These options apply to each disk group referred to on the snap connect command line -- that is, each disk group named explicitly, or for which any host LVM entity within the group is named.

	o	With neither option given, for each disk group referred to, either the source disk group itself must be mentioned or all storage in the source group must be mentioned (using the names of host LVM entities). In the second case, if any storage is not mentioned, the operation will fail. Whenever a name needed to connect an entity in the destination disk group has not been specified, the name will be taken from the source disk group. If that name cannot be used, the operation will fail.
	o	With -autoexpand given, for each disk group referred to, either the disk group itself or some of the host LVM entities in the group must be mentioned. However, in the second case not all of the storage in the disk group needs to be named. Whenever a name needed to connect an entity in the destination disk group has not been specified, the name will be taken from the source disk group. If that name cannot be used, the operation will fail.
	o	With -autorename given, for each disk group referred to, either the disk group itself or some of the host LVM entities in the group need to be mentioned. However, in the second case not all of the entities in the group have to be named (because -autorename implies -autoexpand). Whenever a name needed to connect an entity in the destination disk group has not been specified, the operation will generate a new, unused name for the destination entity, using the rules described above in the section Internally-Generated Names.

In all cases, whether or not -autorename is given, snap connect chooses internally-generated names for the copies of filer LUNs that it creates, as described in the section Internally-Generated Names. Initiator group processing for this operation, including the handling of the -igroup option, occurs as described above in the section Initiator Groups. Note: On a Linux originating host, the snapdrive snap connect operation works only with Linux LVM2, and Snapshot copies taken by SnapDrive for UNIX 2.2. Examples: # snapdrive snap connect -hostvol srcdg/myvol destdg/myvol \ -snapname filer1:/vol/vol1:mysnapshot # snapdrive snap connect -vg myvg -snapname snap1 # snapdrive snap connect -dg src_dg1 dest_dg1 \ -snapname filer1:/vol/vol1:mysnapshot snapdrive snap disconnect -lun long_lun_name [lun_name ...] [-devicetype {shared | dedicated}] snapdrive snap disconnect { -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [{ -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] ...] [-full][-devicetype {shared | dedicated}] The disconnect operation is the inverse of the connect operation, and removes the mappings from one or more host file_specs to the temporary LUNs that were originally created by snap connect. The snapshot from which the temporary LUNs were copied is not modified in any way, but the LUNs themselves are deleted. To disconnect the temporary LUNs without deleting them, use the storage disconnect command. If the -full option is given, the operation will attempt to disconnect the named snapshot even if a host-side entity is named that contains other entities (e.g., a disk group is named that contains one or more host volumes). Without -full, only empty host-side entities may be specified. The file_spec parameter must be one of -lun, -vg, -dg, -lvol, -hostvol, or -fs. Note that -lun may be freely combined with the other parameters in the same command line. Also note that -fs can specify any of three different kinds of file system: one residing in a logical volume, one residing directly in a LUN, or an NFS-mounted directory tree. If one NFS directory tree is given, all file_specs given must name such trees. As for snap restore, for snap disconnect it is an error to specify a subset of the host volumes and/or file systems contained in each target disk group. Unlike for snap restore, for snap disconnect there is no way to override this behavior. LUNs accessed by snap disconnect must be mapped using igroups that contain only initiators from the local host, or the operation will fail. Since this operation deletes filer LUNs, it will not be attempted on a LUN that is mapped by an igroup containing initiators from another host. Examples: # snapdrive snap disconnect -hostvol dg5/myvolume # snapdrive snap disconnect -vg vg1 vg10 # snapdrive snap disconnect -quiet -dg dg1 dg2 dg3 snapdrive snap restore -snapname snap_name { -lun | -vg | -dg | -fs | -lvol | -hostvol | -file } file_spec [file_spec ...] [{ -lun | -vg | -dg | -fs | -lvol | -hostvol | -file } file_spec [file_spec ...] ...] [-force [-noprompt]] [{-reserve | -noreserve}][-devicetype {shared | dedicated}] The restore operation restores the data in one or more host disk groups from the snapshot indicated by snap_name. This operation replaces the existing contents of the LUNs that make up the host disk groups with the contents of the LUNs found in the specified snapshot. The snapshot named may refer to disk groups from multiple filer volumes, either from the same filer or from multiple filers. If any of the file_spec arguments given currently exist on the local host, snap_name may be given as a short-form snapshot name. That is, the filer and filer volume name for the snapshot may be omitted, and the snapshot will be sought in the volume containing the LUNs that underlie the existing file_spec arguments. If none of the specified file_spec arguments exist, then snap_name must be given as a long-form snapshot name, including the relevant filer and filer volume name. Because all the contents of each disk group are restored together, it is an error to give only a subset of the host volumes and/or file systems in each disk group. This can be overridden with the -force option, but the entire disk group will still be restored. See the examples for details. The file_spec parameter must be one of -lun, -vg, -dg, -lvol, -hostvol, -fs or -file. It is an error to combine -lvol with -hostvol, or -vg with -dg. Note that -fs can specify any of three different kinds of file system: one residing in a logical volume, one residing directly in a LUN, or an NFS-mounted directory tree. For this operation, NFS directory trees and other kinds of file_specs may be named on the same command line. The -file parameter may be used to restore a single file from a snapshot of an NFS-mounted directory tree. It causes the directory containing the named file to be re-created (if it doesn’t already exist) so that the file can be restored, but does not restore any other files that were present in the directory tree when the snapshot was made. The -noreserve option causes any LUNs created by the operation to be created with space reservation disabled on the filer. By default, LUNs are created with space reservation enabled. The option -reserve explicitly requests the use of space reservation; the option does not change the default behavior of the operation, and is provided only for consistency with snap connect and storage create. Note that restore of a disk group that has changed in configuration since the snapshot was taken will fail. This can be overridden in some cases using the -force option. If you have added or removed a host volume or file system, changed the way your data is striped, or resized any volume manager entity above the disk group level, you can override and restore from an older snapshot. However, if you have added or removed LUNs from a disk group, restore will reliably fail and cannot be overridden. It is important to take a new snapshot whenever a LUN has been added to or removed from a disk group. If -force appears and would force an action to occur that would otherwise not be attempted, this operation will prompt the user to confirm that it should proceed, unless -noprompt is also given. If both options are given, the operation proceeds with no further ado. All the LUNs in any disk groups being restored must be mapped to the host, online and available at the time of the restore. This restriction may be lifted in later releases. Restore can take several minutes. Users should bear this in mind when issuing a snap restore. Note that if the filer volume contains only LUNs (i.e. no NAS data), and all the LUNs on the volume are being restored, then restore can be done nearly instantaneously. Examples: # snapdrive snap restore -hostvol dg9/MyVol -snapname filer1:/vol/vol1:OldSnap42 # snapdrive snap restore -fs /mnt/dir -snapname filer1:/vol/vol1:NewSnap33 # snapdrive snap restore -vg OracleVg1 Datavg -snapname toaster:/vol/vol1:snap1 # snapdrive snap restore -dg dg1 dg2 -snapname filer1:/vol/vol1:Tuesday # snapdrive snap restore -file /mnt/dir/acctg/table1 -snapname filer1:/vol/vol1:NewSnap33 For a host called DBserver, a disk group dg1 has host volumes myvol1 and myvol2. Volume dg1/myvol2 has a file system mounted on /fs2. The disk group dg1 has three luns in it: toaster:/vol/vol1/lun0, toaster:/vol/vol1/lun1, and toaster:/vol/vol1/lun2. The following commands are all valid, and will all restore the same data: Examples: # snapdrive snap restore -dg dg1 -snapname toaster:/vol/vol1:snap1 # snapdrive snap restore -vg dg1 -snapname toaster:/vol/vol1:snap1 # snapdrive snap restore -hostvol dg1/myvol2 dg1/myvol1 -snapname toaster:/vol/vol1:snap1 # snapdrive snap restore -lvol dg1/myvol2 -fs /fs2 -snapname toaster:/vol/vol1:snap1 The following commands are not valid, because they do not specify the entire set of volume manager entities to be restored: Examples: # snapdrive snap restore -fs /fs2 -snapname toaster:/vol/vol1:snap1 # snapdrive snap restore -hostvol dg1/myvol1 -snapname toaster:/vol/vol1:snap1 Release 2.2 limitations: snapdrive 2.2 will not restore the following: root disk group, shared disk group (shared with another host in a host cluster), boot device, or swap device.

Storage Provisioning

The snapdrive commands to perform complete storage provisioning (filer-side as well as host-side operations) are all of the form:

snapdrive storage [operation [options ...] ] [-devicetype {shared | dedicated}]

where operation is one of show, list, create, delete, resize, connect, or disconnect. snapdrive storage { show | list } -filer filer_name [filer_name ...] [-verbose] [-quiet] [-devicetype {shared | dedicated}] snapdrive storage { show | list } -filervol long_filer_path [filer_path ...] [-verbose] [-quiet] [-devicetype {shared | dedicated}] snapdrive storage { show | list } -lun long_lun_name [lun_name ...] [-verbose ] [-quiet ] [-devicetype {shared | dedicated}] snapdrive storage { show | list } { -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [{ -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...]] [-verbose] [-quiet] snapdrive storage { show | list } { -all | -devices } [-devicetype {shared | dedicated}] The storage show (or storage list) command displays either information about filer LUNs accessible to the current host, or information about host LVM entities (and the filer LUNs that underlie them). The first three forms display information on filer LUNs. A filer or filer volume may be named, which will be searched for any LUNs it contains. Alternatively, a set of LUNs may be named directly, with the target filer and filer volume specified using long_lun_name. The fourth form displays information on all of the host LVM entities given as arguments, as well as on the filer LUNs associated with them. The final form displays information on all connected filer LUNs. The option -devices produces output describing the host devices corresponding to connected LUNs. The option -all produces the same output, and also displays information on host LVM entities associated with each connected LUN. The -verbose option provides more detailed output, detailing the storage hierarchy down to and including the backing LUNs. The -quiet option silences all output, diagnostic and normal, and silently overrides -verbose, which can be useful for existence checking within a script. Here are some examples: # snapdrive storage show -verbose -filer BigFiler3 BigFiler4 # snapdrive storage show -dg dg1 dg2 # snapdrive storage show -quiet -dg QA_dg_test # snapdrive storage show -verbose -filervol BigFiler3:/vol/vol1 # snapdrive storage show -lun BigFiler3:/vol/vol1/lunA lunB lunC # snapdrive storage show -filer BigFiler3 BigFiler4 # snapdrive storage show -fs /mnt/fs21 /mnt/fs41 # snapdrive storage show -hostvol dg2/vol1 dg4/myvol3 # snapdrive storage show -dg dg2 dg4 # snapdrive storage show -dg dg2 -fs /mnt/fs42 # snapdrive storage show -hostvol dg2/vol3 -fs /mnt/fs42 For filer LUNs and for host LVM entities, storage show outputs the same basic information, regardless of the specific file_spec requested. For each disk group specified on the command line (or indicated by other file_specs on the command line), the following will be printed:

	o	If there is a disk group associated with the file_spec, a line is printed with the name of the disk group.
	o	If there are one or more host volumes in the disk group, they will be listed after the disk group, one per line.
	o	If there are one or more file systems associated with any of the host volumes, they will be listed next, one per line. The file system will be noted as persistent if a line exists in the host’s mount table file that specifies the current mount point and the device or NFS directory tree currently associated with the mount point. (In other words, the "mount" must be present in the file.) Otherwise, the file system will be noted as non-persistent. In case of AIX, if the mount entry exists in the mount table file (/etc/filesystems) and if the option "mount = false" is present for that mount entry, then the file system will be noted as non-persistent.
	o	If the -verbose option was given, a line is output indicating the protocol over which the storage being described is accessible. The protocol will be output as either NFS or SCSI. The latter name indicates that the storage is accessible via iSCSI, FCP or both.
	o	If there is no file system, host volume, or disk group, then these lines are omitted. The LUN-based information will be printed for all LUNs indicated on the command line, regardless of whether they have an associated disk group, host volume, or file system.

After this information, a line of information about each underlying filer LUN will be printed. Each line indicates: a host device file corresponding to the LUN, the adapter through which the LUN is accessible, an indication of whether this device and adapter are a primary path to the LUN, the size of the LUN, the protocol(s) over which the LUN is accessible, the LUN state and the pathname of the LUN on the filer. The protocols are output as fcp, iscsi or fcp+iscsi (if both are in use). Example: # snapdrive storage show -dg dg1 dg: dg1 hostvol: /dev/vx/dsk/myvol1 state: AVAIL hostvol: /dev/vx/dsk/hisvol2 state: AVAIL fs: /dev/vx/dsk/dg1/myvol1 mount point: /pub (persistent) device filename adapter path size proto state lun path ----------------- ------- ---- ---- ----- ----- ---------- /dev/rdsk/c1t0d1s2 - P 10g fcp online myfiler:/vol0/lun-1 /dev/rdsk/c2t0d1s2 - - 10g fcp online myfiler:/vol0/lun-1 /dev/rdsk/c1t0d5s2 - P 10g fcp online myfiler:/vol0/lun-5 /dev/rdsk/c2t0d5s2 - - 10g fcp online myfiler:/vol0/lun-5 The -all option groups accessible LUNs by the disk group (if any) of which they are a part. For LUNs that are part of a disk group, output consists of the same host LVM-related information described above, followed by the same LUN-related information shown. For LUNs not part of a disk group, output consists only of the LUN-related information shown. For the -devices option, output for each LUN consists only of the LUN-related information shown. There is no attempt made to associate LUNs with host LVM entities. Output for a file system residing directly in a raw device describes the device and the mount point, as in: # snapdrive storage show -fs /mnt/acctfs_raw raw device: /dev/vx/dmp/c1t1d1s2 mount point: /mnt/acctfs_raw (persistent) device filename adapter path size proto state lun path -------------------- ------- ---- ---- ----- ----- --------------- /dev/vx/dmp/c1t1d1s2 - P 108m fcp online myfiler:/vol/vol1/acctR_lun Output for a NFS-mounted directory tree (named using its mount point via -fs) describes the "NFS device" (the pathname of the mounted tree), plus the mount point. For instance: # snapdrive storage show -fs /mnt/acctfs_nfs NFS device: myfiler:/vol/vol1 mount point: /mnt/acctfs_nfs (non-persistent) Release 2.2 limitations: The adapter name is not filled in. Non-primary paths will have the path status printed as ’-’ rather than ’S’ (secondary). Only file systems located within host volumes will be located by storage show without being directly named. In other words, information on an NFS-mounted directory tree or a file system residing directly in a raw LUN will be output only if the associated mount point is named on the command line (using -fs). The storage show operation will show the same basic output for filers, filer volumes, or LUNs, but will limit the output shown to only the filers, filer volumes, or LUNs specified. However, if a disk group has LUNs from more than just the specified filer or filer volume, or contains more LUNs than those specified, all LUNs will still be shown. snapdrive storage create -lun long_lun_name [lun_name ...] -lunsize size [{ -dg | -vg } dg_name] [-igroup ig_name [ig_name ...]] [{ -reserve | -noreserve }] [-devicetype {shared | dedicated}] snapdrive storage create host_lvm_fspec -filervol long_filer_path -dgsize size [-igroup ig_name [ig_name ...]][{ -reserve | -noreserve }][-devicetype {shared | dedicated}] snapdrive storage create -fs file_spec -nolvm [-fstype type] [-fsopts options] [-mntopts options] [-nopersist] { -lun long_lun_name | -filervol long_filer_path } -lunsize size [-igroup ig_name [ig_name ...]] [{ -reserve | -noreserve }][-devicetype {shared | dedicated}] snapdrive storage create host_lvm_fspec -lun long_lun_name [lun_name ...] -lunsize size [-igroup ig_name [ig_name ...]] [-devicetype {shared | dedicated}] The storage create operation is aimed at simplifying the process of host-side provisioning of storage on filers, while still enabling storage management through host-side volume managers. The first form of this command will create one or more LUNs. The LUN names given to the -lun option specify the filer and filer volume where the LUNs are to be created, while the value given to the -lunsize option specifies the size in bytes of each LUN created. snapdrive automatically performs all of the tasks associated with host preparation and discovery for each LUN, as well as mapping and connecting to it. The second form of the command creates a file system directly inside a LUN. snapdrive performs all actions needed to set up the file system, including the creation of the required LUN. The user either specifies the name of the LUN he wants to create (with the -lun option), or specifies the filer and filer volume where the LUN is to be created (with the -filervol option). In either case, the user specifies the size of the LUN with the -lunsize option, and the needed LUN is created automatically. The third form of the command creates a host LVM entity -- a file system, logical volume or disk group -- specified by host_lvm_fspec. snapdrive performs all actions needed to set up the requested entity, including the creation of the required disk group and LUNs. The user specifies the the filer and filer volume where the LUNs are to be created using the -filervol option, but does not specify the LUNs, which are created automatically. To control the size of the host LVM entity created, the user specifies either the size in bytes of the underlying disk group, or the size in bytes of the underlying LUN, using the -dgsize option or the -lunsize option. The last form of the command also creates a host LVM entity, but allows the user to specify exactly what LUNs are to be created as part of the higher-level entity. In this form, the user specifies the target filer and filer volume via the -lun option, and controls LUN size with the -lunsize option. The size of the LVM entity is whatever results from the aggregated size of the LUNs that are specified. A host_lvm_fspec has one of the following formats. To create a file system inside a logical volume:

-fs file_spec [-fstype type] [-fsopts options] [-mntopts options] [-nopersist] [{ -lvol | -hostvol } file_spec] [{ -dg | -vg } dg_name]

To create a logical volume:

{ -lvol | -hostvol } file_spec [{ -dg | -vg } dg_name]

To create a volume group:

{ -dg | -vg } dg_name

In other words, a host_lvm_fspec may specify a file system, a logical volume, or a disk group. The "top-level" entity being created must be named, and underlying entities may be named, but will be created with internally-generated names if they are not mentioned. If filer LUNs are not explicitly mentioned, they too will be created with internally-generated names. The details of name generation are described above in the section Internally-Generated Names. In specifying LUNs explicitly to this command, the following options have the indicated meaning. The -dg or -vg option names a disk group to be created to contain all newly-created LUNs. The disk group must not already exist. Option -lunsize specifies the size of each LUN to be created. The first LUN name given with the -lun option specifies the filer name and filer volume to be used for LUN creation, as well as the LUN name within the volume. Any LUN names given after the first one may be pathnames relative to the root of the named volume, with no filer name or filer volume components. If they are, the named LUNs are created in the volume used for the first LUN. Alternatively, LUN names after the first may re-specify a filer volume or a filer name plus filer volume. The new values given then override the previous ones. In using this command to create a logical volume or file system without LUNs explicitly specified, snapdrive will choose sensible system-wide defaults for the number of LUNs, the respective LUN-id’s, the size of each LUN, and the names of the associated disk/volume groups, based on the name of the host volume or file system. Administrators desiring a greater degree of control are able to adjust the system-wide defaults in snapdrive.conf. The -noreserve option causes any LUNs created as a result of this operation to be created with space reservation disabled. By default, they will be created with space reservation enabled. The -reserve option confirms that any LUNs created as a result of this operation will be created with space reservation enabled; again, this is the default. For file system creation, the supported file system types depend on the available LVMs. The desired type can be specified using the -fstype option. For each platform, the following type strings may be specified to -fstype:

	Solaris		VxFS or UFS
	HP-UX		VxFS
	AIX		JFS or JFS2
	Linux		ext3

The type name can be spelled in any combination of upper- and lowercase. When a file system is being created within an existing disk group or logical volume, the file system type is usually implied by the existing entity. For file system creation, several options are provided to control details of the process:

	-fsopts		This option is used to specify options to be passed to whatever host operation creates the new file system (e.g., mkfs). The argument following -fsopts should contain exactly the text to be passed to the command. Usually, this will need to be specified as a quoted string.
	-mntopts		This option is used to specify filesystem-specific options to be passed to whatever host operation mounts a new file system (i.e., the mount command). Normally, the argument given to this option will be a comma-separated list of option names. This list will be passed as appropriate to the mount command, and will be inserted verbatim in any line added to the host mount table file ("fstab" file) as a result of the storage create operation.
	-nolvm		This option causes the new file system to be created directly inside the LUN named, without any LVM infrastructure.
	-nopersist		This option suppresses any update to the host mount table file ("fstab" file). By default, the file is updated to contain a line listing the file system mount resulting from the storage create operation.

Initiator group processing for this operation, including the handling of the -igroup option, occurs as described above in the section Initiator Groups. Examples: # snapdrive storage create -lun kipper:/vol/vol1/lunA lunB lunC \ -dg data_dg -lunsize 10g # snapdrive storage create -lvol dg5/myvol -filervol filer2:/vol/acct -dgsize 500m # snapdrive storage create -fs /mnt/acctfs -filervol filer2:/vol/acct -dgsize 100m # snapdrive storage create -fs /mnt/acctfs -fstype vxfs \ -filervol acctfiler:/vol/acct -dgsize 1g # snapdrive storage create -fs /mnt/acctfs -fsopts "-o largefiles" \ -filervol acctfiler:/vol/acct2 -dgsize 10g # snapdrive storage create -fs /mnt/acctfs -mntopts "tmplog,blkclear" \ -filervol acctfiler:/vol/acct2 -dgsize 10g Release 2.2 limitations: snapdrive storage delete -lun long_lun_name [lun_name ...] [-devicetype {shared | dedicated}] snapdrive storage delete { -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [{ -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] ...] [-full] [-devicetype {shared | dedicated}] The storage delete operation removes the host-side entities specified, together with all underlying host-side entities and the underlying filer LUN(s) backing them. The -full option will attempt to delete host-side entities that contain other entities. For instance, it enables attempted deletion of a disk group that contains one or more host volumes. Without -full, only an empty host-side entity may be named for deletion. The first form of this operation deletes a set of explicitly-named LUNs. In this form, the first LUN name given with the -lun option specifies the filer name and filer volume to be used for LUN creation, as well as the LUN name within the volume. Any LUN names given after the first one may be pathnames relative to the root of the named volume, with no filer name or filer volume components. If they are, the named LUNs are sought in the volume used for the first LUN. Alternatively, LUN names after the first may re-specify a filer volume or a filer name plus filer volume. The new values given then override the previous ones. The second form of this operation accepts the names of one or host-side entities, and deletes all of the host- and filer-side components of each entity named. Note that -fs may name either a file system residing in a logical volume, or a file system residing directly in a LUN. LUNs accessed by storage delete must be mapped using igroups that contain only initiators from the local host, or the operation will fail. Since this operation deletes filer LUNs, it will not be attempted on a LUN that is mapped by an igroup containing initiators from another host. Examples: # snapdrive storage delete -lun filer1:/vol/vol1/lun1 lun2 # snapdrive storage delete -full -dg dg1 dg2 dg3 # snapdrive storage delete -lvol mydg/vol3 mydg/vol5 # snapdrive storage delete -fs /mnt/acct2 snapdrive storage resize { -vg | -dg } file_spec { -growby | -growto } size [-addlun [-igroup ig_name [ig_name ...]] [{-reserve | -noreserve}]] The resize operation increases the size of the host-side file_spec either by size bytes (if -growby is given), or to size bytes (if -growto is given). If -addlun is specified, the growth is performed by adding a new, internally-generated LUN to the underlying disk group. Otherwise, the growth is performed by increasing the size of the final LUN in the underlying disk group. In both cases, the size of the entity named by file_spec is also increased to include the newly-added storage. If the host doesn’t support changing LUN sizes, and if -addlun is not given, the resize operation will fail (and may be retried using -addlun). In all forms of the operation, the file_spec parameter must be one of -vg or -dg. The -noreserve option causes any LUN created by the operation to be created with space reservation disabled on the filer. By default, the LUN is created with space reservation enabled. The option -reserve explicitly requests the use of space reservation; the option does not change the default behavior of the operation, and is provided only for consistency with snap connect and storage create. Initiator group processing for this operation, including the handling of the -igroup option, occurs as described above in the section Initiator Groups. When -addlun is specified, the filer LUN created is named as described above in the section Internally-Generated Names. Examples: snapdrive storage resize -dg my_dg -addlun -growby 155m snapdrive storage resize -dg my_dg -growto 155m Release 2.2 limitations: It is not possible to use storage resize to decrease the size of an entity. It is not possible to construct a disk group (or, therefore, a logical volume or file system) using LUNs from more than one filer volume. Hence multiple volumes may not be specified in the list of LUNs given to -lun; all LUNs must reside in the same volume. Resize is not supported directly on logical volumes or file systems. snapdrive storage connect -lun long_lun_name [lun_name ...] [-igroup ig_name [ig_name ...]] [-devicetype {shared | dedicated}] snapdrive storage connect -fs file_spec -nolvm -lun long_lun_name [-igroup ig_name [ig_name ...]] [-nopersist] [-mntopts options] [-devicetype {shared | dedicated}] snapdrive storage connect -fs file_spec { -hostvol | -lvol } file_spec -lun long_lun_name [lun_name ...] [-igroup ig_name [ig_name ...]] [-nopersist] [-mntopts options] [-devicetype {shared | dedicated}] The connect operation maps existing LUN(s) to the host, performing discovery on that host. LUN contents are not modified in any way. The second form of the operation is used to connect to and mount a file system stored directly in a raw LUN. In this case, file_spec specifies the directory at which the file system is to be mounted. The third form of the operation is used to connect to and mount an LVM-based filesystem within a logical volume stored in one or more LUNs. In this case, the file_spec provided to -fs specifies the directory at which the file system is to be mounted, while the file_spec given to -hostvol or -lvol names the containing volume group and logical volume. The first LUN name given with the -lun option specifies the filer name and filer volume where LUNs will be sought, as well as specifying the LUN name within the volume. Any LUN names given after the first one may be pathnames relative to the root of the named volume, with no filer name or filer volume components. If they are, the named LUNs are sought in the volume used for the first LUN. Alternatively, LUN names after the first may re-specify a filer volume or a filer name plus filer volume. The new values given then override the previous ones. Initiator group processing for this operation, including the handling of the -igroup option, occurs as described above in the section Initiator Groups. -mntopts option can be used to specify filesystem-specific options to be passed to whatever host operation mounts a new file system (i.e., the mount command). Normally, the argument given to this option will be a comma-separated list of option names. This list will be passed as appropriate to the mount command, and will be inserted verbatim in any line added to the host mount table file ("fstab" file) as a result of the storage connect operation. Examples: snapdrive storage connect -lun filer1:/vol/vol1/ontap_lun2 snapdrive storage connect -lun filer1:/vol/vol1/ontap_lun2 \ ontap_lun3 ontap_lun4 snapdrive storage disconnect -lun long_lun_name [lun_name...] [-devicetype {shared | dedicated}] snapdrive storage disconnect {-vg | -dg | -fs | -lvol | -hostvol} file_spec [file_spec ...] [{-vg | -dg | -fs | -lvol | -hostvol} file_spec [file_spec ...] ...] [-full][-devicetype {shared | dedicated}] The disconnect operation removes one or more mappings (established by create or connect operations) from the specified host file_specs to the underlying LUNs backing them. LUN contents are not modified in any way. The LUNs involved may be named either directly or via the disk group they belong to. In the first form of the command, the first LUN name given with the -lun option specifies the filer name and filer volume where the target LUNs reside, as well as the LUN name within the volume. Any LUN names given after the first one may be pathnames relative to the root of the named volume, with no filer name or filer volume components. If they are, the named LUNs are sought in the volume used for the first LUN. Alternatively, LUN names after the first may re-specify a filer volume or a filer name plus filer volume. The new values given then override the previous ones. In the second form of the command, the named host-side entities are disabled, and then the associated LUNs are disconnected. The contents of the LUNs are not disturbed. In particular, it remains possible to reconnect the LUNs and re-establish access to any LVM entities they contain. This form of the command may be used to disconnect LVM entities that were originally accessed via snap connect operation, as well as other LVM entities. When the temporary LUNs underlying LVM entities accessed via snap connect are disconnected using this operation, the LUNs remain accessible on the filer, just as any other LUNs would. Note that -fs may name either a file system residing in a host volume, or a file system residing directly in a LUN. If the -full option is given, this operation will attempt to disconnect host-side entities that contain other entities, for instance a disk group that contains one or more host volumes. Without -full given, only empty host-side entities may be specified. LUNs accessed by storage disconnect must not be mapped using igroups that contain a mixture of initiators from the local host and other initiators, or the operation will fail. LUNs are removed successfully from igroups that contain only local initiators. LUN mappings in igroups that contain only non-local initiators are ignored. Examples: snapdrive storage disconnect -dg dg1 dg2 dg3 snapdrive storage disconnect -lvol dg1/mylvol1 snapdrive storage disconnect -lun filer1:/vol/vol1/lun1

Host-Only Provisioning

The snapdrive command to perform host-side storage provisioning (with no filer-side effects) is of the form:

snapdrive host [operation [options ...] ]

In the current release, two host operations, host connect and host disconnect, are provided. snapdrive host connect -lun long_lun_name [lun_name ...] snapdrive host connect -fs file_spec -nolvm -lun long_lun_name [-nopersist] [-mntopts options] snapdrive host connect -fs file_spec { -hostvol | -lvol } file_spec -lun long_lun_name [lun_name ...] [-nopersist] [-mntopts options] The host connect operation performs the host portion of the actions taken by storage connect. That is, it connects the named storage without changing any state on the filer. The operation therefore assumes that any needed LUNs are already mapped on the filer to the current host. This operation allows the user to reconnect LUNs that were disconnected with a previous host disconnect operation. This operation could also be used to connect the host to LUNs that have been fully-provisioned (and mapped to the host) on the filer outside SnapDrive for Unix. This operation accepts the same three forms of command line as does storage connect, which respectively connect LUNs, a file system built directly atop a LUN, or a file system atop a host volume atop one or more LUNs. snapdrive host disconnect -lun long_lun_name [lun_name...] snapdrive host disconnect { -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] [{ -vg | -dg | -fs | -lvol | -hostvol } file_spec [file_spec ...] ...] [-full] The host disconnect operation performs the host portion of the actions taken by storage disconnect . That is, it disconnects the named host-side entities without changing any state on the filer where the underlying LUNs reside. This operation performs all host-side actions involved in making the host-side entities inaccessible from the current host, but avoids the risk of disconnecting other hosts from the underlying filer LUNs if the current host and other hosts share an igroup on the filer. This operation accepts the same two forms of command line as does storage disconnect, which respectively disconnect a set of LUNs or the named LVM entities. If the -full option is given, this operation will attempt to disconnect host-side entities that contain other entities, for instance a disk group that contains one or more host volumes. Without -full given, only empty host-side entities may be specified. Examples: snapdrive host disconnect -dg dg1 dg2 dg3 snapdrive host disconnect -lvol dg1/mylvol1

Snapdrive Configuration

snapdrive config access { show | list } filername This operation displays the access that the current host has to the filer filername. The level of access controls what operations the host can perform on that filer. Defined access levels and the commands that they enable are as follows:

	NONE	no access permitted.
	SNAP CREATE	host can execute snap create only.
	SNAP USE	host can execute snap delete and snap rename only.
	SNAP ALL	host can execute all snap operations, including snap restore, but only those.
	STORAGE CREATE DELETE	host can execute only storage create, storage delete, storage resize, snap connect and snap disconnect.
	STORAGE USE	host can execute storage connect and storage disconnect only.
	STORAGE ALL	host can execute all storage operations, as well as snap connect and snap disconnect, but only those.
	ALL ACCESS	host can execute all snap and storage operations.

Setting up access control from a given host to a given filer is a manual operation. The access from a given host is controlled by a file residing in the root volume of the affected filer. This file has the name /vol/vol0/sdprbac/sdhostname.prbac, where hostname is the name of the affected host, as returned by gethostname(3). The user should ensure that this file is readable, but not writeable, from the host that will access it. This file is used as follows:

	o	If the file does not exist at all, the level of access from the current host is controlled by the snapdrive.conf variable all-access-if-rbac-unspecified. If this variable has the value on, or if it is not defined, all access is allowed. If this variable has the value off, no access is allowed.
	o	If the file is present, it should contain exactly one of the access level names from the list given above. The host will then be granted only that level of access. Each level of access is separate from all the others; having one level of access does not imply having any other level of access.
	o	If the file is present but cannot be read, or if it has invalid contents, no access is allowed.

snapdrive config set user_name filername [filername ...] snapdrive config delete filername [filername ...] snapdrive config list These snapdrive config operations control which user/password combination is used to access each filer. The config set operation sets the user/password combination to be used to access one or more filers, and the config delete operation removes the filer-to-user/password mapping. The config list operation displays the user configured for each filer. Even if no password is configured for a filer, the administrator must run config set with the filername and user and supply a null password when prompted, before snapdrive will be able to access the filer. Please note that this must be done on each host that will run snapdrive. For example, to configure access to filer toaster for user root: # snapdrive config set root toaster Password for root: Retype Password: To remove access to toaster on this host: # snapdrive config delete toaster To configure access to several filers with the same user and password: # snapdrive config set root toaster handmixer blender Password for root: Retype Password: To display the configured user/filer mappings: # snapdrive config list user name filer name ----------------------------- rumplestiltskins rapunzel longuser mediumfiler snapdrive config prepare luns -count count [-devicetype {shared | dedicated}] This operation ensures that the host is prepared for the potential creation of count new LUNs residing on a filer already mapped to the host. As of the 2.2 release, only two platforms require such preparation (so this operation is a no-op elsewhere). On Solaris, this operation ensures preparedness for the requested number of potential new LUNs by adding entries to the file /kernel/drv/sd.conf, if necessary. For each LUN that requires an update to sd.conf, an entry is generated for each SCSI target to which a filer is mapped. On Solaris 8, in order for new sd.conf entries to be usable, the host must be rebooted. This operation outputs a warning to that effect whenever a reboot is necessary. On Linux, this operation ensures preparedness for the requested number of potential new LUNs by adding new /dev/sg device files, if necessary. For each potential LUN that is not currently prepared for, a new device file is created. Note that this operation does not simply prepare for count new LUNs each time it’s invoked. Rather, the operation does whatever is required to ensure that count new LUNs are available. So for instance if the host is already prepared for count new LUNs to be created, then this operation has no effect. When this command is specified with the option -devicetype dedicated the behavior is same as mentioned above. With -devicetype shared option specified, the comand ensures that count new LUNs are available on all nodes of cluster. snapdrive config check luns This operation checks how many LUNs could currently be created on the host without exceeding any host-local limit. As of the 2.2 release, only two platforms have such limits (so this operation is a no-op elsewhere). On Solaris, this operation scans the file /kernel/drv/sd.conf to determine how many unused entries exist that would be suitable for filer-based LUNs. On Linux, this operation scans the existing /dev/sg files to determine how many are unused. snapdrive config check cluster This operation currently works only on Solaris, in VERITAS SFRAC environment. This command checks for Cluster Status, CVM status, GAB status, Snapdrive version, compares multipathing type and transport type in cluster nodes. snapdrive config show [host_file_name] This operation outputs the snapdrive configuration options. These options are controlled from the snapdrive.conf file, which is located in the snapdrive installation directory (for example, /opt/NTAPsnapdrive/snapdrive.conf on Solaris). The show operation shows the current snapdrive configuration data (writing to the file host_file_name if one is given). The syntax is a series of name/value pairs of the form config-option-name=value # optional comment one per line. The value given may be a number, a string, or one of the case-insensitive tokens "on" or "off" for boolean options (equivalent to supplying "1" or "0", respectively). The format of the file follows the same quoting and comment conventions as snapdrive run-time scripts. A string (perhaps containing white space) may be quoted either by quoting the entire name/value pair, or by quoting just the value: "config-option-one=some white space" # sample option one config-option-two="more white space" # sample option two config-option-2B=’single quotes too’ # both quote marks work number-of-widgets=137 # control widget usage enable-some-option=off # disable some-option Supported configurable items and their default settings may vary across platforms and releases. Current configurable items and their settings can always be found using the config show operation, for example: # snapdrive config show # # Snapdrive Configuration # file: /opt/NTAPsnapdrive/snapdrive.conf # Version 2.2 (Change 577538 Built Mon Sep 11 19:00:45 IST 2006) # # # Default values are shown by lines which are commented-out in this file. # If there is no un-commented-out line in this file relating to a particular value, then # the default value represented in the commented-out line is what SnapDrive will use. # # To change a value: # # -- copy the line that is commented out to another line # -- Leave the commented-out line # -- Modify the new line to remove the ’#’ and to set the new value. # -- Save the file and exit # audit-log-file="/var/log/sd-audit.log" # audit log file trace-log-file="/var/log/sd-trace.log" # trace log file recovery-log-file="/var/log/sd-recovery.log" # recovery log file autosupport-enabled=off # Enable autosupport (requires autosupport-filer be set) autosupport-filer="" # Filer to use for autosupport (filer must be configured for autosupport) audit-log-max-size=20480 # Maximum size (in bytes) of audit log file audit-log-save=2 # Number of old copies of audit log file to save available-lun-reserve=8 # Number of LUNs for which to reserve host resources contact-http-port=80 # HTTP port to contact to access the filer contact-ssl-port=443 # SSL port to contact to access the filer device-retries=3 # Number of retries on Ontap filer LUN device inquiry device-retry-sleep-secs=1 # Number of seconds between Ontap filer LUN device inquiry retries enable-implicit-host-preparation=off # Enable implicit host preparation for LUN creation filer-restore-retries=140 # Number of retries while doing lun restore filer-restore-retry-sleep-secs=15 # Number of secs between retries while restoring lun filesystem-freeze-timeout-secs=300 # File system freeze timeout in seconds default-noprompt=off # A default value for -noprompt option in the command line mgmt-retries=3 # Number of retries on ManageONTAP control channel mgmt-retry-sleep-secs=2 # Number of seconds between retries on ManageONTAP control channel mgmt-retry-sleep-long-secs=90 # Number of seconds between retries on ManageONTAP control channel (failover error) prepare-lun-count=16 # Number of LUNs for which to request host preparation PATH="/sbin:/usr/sbin:/bin:/usr/lib/vxvm/bin:/usr/bin:/opt/NTAP/SANToolkit/bin:/opt/NTAPsanlun/bin:/opt/VRTS/bin:/etc/vx/bin" # toolset search path password-file="/opt/NTAPsnapdrive/.pwfile" # location of password file prefix-filer-lun="" # Prefix for all filer LUN names internally generated by storage create recovery-log-save=20 # Number of old copies of recovery log file to save snapcreate-consistency-retries=3 # Number of retries on best-effort snapshot consistency check failure snapcreate-consistency-retry-sleep=1 # Number of seconds between best-effort snapshot consistency retries snapcreate-must-make-snapinfo-on-qtree=off # snap create must be able to create snapinfo on qtree snapcreate-cg-timeout="relaxed" # Timeout type used in snapshot creation with Consitency Groups. Possible values are "urgent", "medium" or "relaxed". snapcreate-check-nonpersistent-nfs=on # Check that entries exist in /etc/fstab for specified nfs fs. snapconnect-nfs-removedirectories=on # NFS snap connect cleaup unwanted dirs; snapdelete-delete-rollback-with-snap=off # Delete all rollback snapshots related to specified snapshot snaprestore-snapmirror-check=on # Enable snapmirror destination volume check in snap restore snaprestore-delete-rollback-after-restore=on # Delete rollback snapshot after a successfull restore snaprestore-make-rollback=on # Create snap rollback before restore snaprestore-must-make-rollback=on # Do not continue ’snap restore’ if rollback creation fails space-reservations-enabled=on # Enable space reservations when creating new luns snapmirror-dest-multiple-filervolumes-enabled=off # Enable snap restore and snap connect commands to deal with snapshots moved to another filer volume (e.g. via SnapMirror) where snapshot spans multiple filers or volumes default-transport="fcp" # Transport type to use for storage provisioning, when a decision is needed multipathing-type="DMP" # Multipathing software to use when more than one multipathing solution is available trace-enabled=on # Enable trace secure-communication-among-cluster-nodes=off # Enable Secure Communication trace-level=5 # Trace levels: 1=FatalError; 2=AdminError; 3=CommandError; 4=warning, 5=info, 6=verbose trace-log-max-size=0 # Maximum size of trace log file in bytes; 0 means one trace log file per command trace-log-save=100 # Number of old copies of trace log file to save all-access-if-rbac-unspecified=on # Allow all access if the RBAC permissions file is missing use-https-to-filer=off # Communication with filer done via HTTPS instead of HTTP The version can also be displayed by itself: # snapdrive version -v snapdrive Version 2.2 (Change 577538 Built Mon Sep 11 19:00:45 IST 2006) There are three types of logging that are supported by snapdrive. Audit logging provides a history of the snapdrive commands issued. An entry is made when a command is initiated, and another which includes status and time when the command completes. The location of the audit log can be controlled by setting audit-log-file in snapdrive.conf. An empty value disables audit logging. Specifying a valid file name will enable audit logging. A pair of audit log entries looks like this: 15801: Begin uid=2629 gid=30 18:56:26 10/12/06 snapdrive config show 15801: Status=0 18:56:26 09/12/06 The location of the trace log can be controlled by setting trace-log-file in snapdrive.conf. This log reports information useful for diagnosing problems, and its contents may be requested by CS personnel. The location of the recovery log can be controlled by setting recovery-log-file in snapdrive.conf. Some snapdrive operations have the potential to leave the system in an inconsistent or less usable state if interrupted for any reason. This could happen if the user killed the program, or if the host crashed in the middle of an operation. This is primarily an issue for snap restore. Recovering automatically from such a scenario may be complicated, and will not be implemented in the first release. The recovery log records the steps of a snap restore operation, documenting the steps taken and progress made, allowing manual disaster recovery. IMPORTANT NOTE: Users should not attempt manual recovery by themselves from an interrupted restore. Please save the recovery log and call technical support. The default locations of the log files are platform-specific, and can be examined using the snapdrive config show command. Note: Only snap restore writes recovery log entries.

EXIT STATUS

Errors encountered by snapdrive will usually be logged or produce other diagnostic output. snapdrive’s exit status will indicate the result of the operation or sequence of operations. A non-zero exit status indicates that an error occurred, or that an unusual condition arose that snapdrive warned about. See the SnapDrive for Unix Installation and Administration Guide for a complete list of error numbers, error names, and explanations.

FILES

snapdrive.conf

/kernel/drv/sd.conf (Solaris only)

/etc/filesystems (AIX only)

/etc/fstab (HP-UX or Linux only)

/etc/vfstab (Solaris only)

SEE ALSO

SnapDrive for Unix Installation and Administration Guide

BUGS

Helpful interactive wizard support has not yet been added. It could be argued that file_spec names should be allowed to begin with a hyphen, but the clever system administrator can not only work around this easily, but do far more confusing things (like naming volumes "dg_XX", luns "snapshot_YY", and snapshots "volume_ZZ"). NFS-mounted directory trees connected directly from a snapshot using snap connect -readonly are vulnerable to the deletion of the snapshot. If the snapshot is removed, the mount of the directory tree will become stale, with no failsafe available.