VMAX3 Commands

Configuring Storage Pools

The VMAX3 is much easier to configure than previous types of Symmetrix. Most of the work is already done for you as the box comes pre-configured, with all physical drives in the array already placed in Storage Resource Pools (SRPs), managed by Fully Automated Storage Tiering (FAST) and ready for you to use.
If you want to know what is going on under the covers, then physical disks of the same physical type, RAID configuration and performance characteristics are combined into Disk Groups. Disk groups with the same RAID level and emulation type are combined into thin data pools, and then the data pools are combined into an SRP. Data is then allocated and moved around within the SRP by FAST software, depending on its performance requirements. You can have up to 5 SRPs, but EMC recommends that you just have one, unless you need to physically isolate data for regulatory or performance reasons.

So all you need to do, is to define storage groups and allocated them to applications. You can define 16,384 storage groups, so it is quite reasonable to define one for every one of your applications. To define a storage group, use the symsg command:

symsg -sid 038 create app1_sg -slo silver -workload oltp

The storage group name can have of up to 64 alphanumeric characters, hyphens (-), and underscores (_) and the names are not case sensitive.
The -slo parameter is for the service level objective. You use this to tell FAST what average response time you want to see for this storage group. Options are Diamond, Platinum, Gold, Silver, and Bronze, and also the default, Optimized, which has no explicit response time target associated with it.
The -workload or -wl parameter defines what type of workload you expect for this storage groups. Options are 'oltp', which is small blocks IO, 'oltp_rep' which is oltp with replication, 'dss', which is large blocks IO, 'dss_rep' which is dss with replication and 'none' which is the default and means just let FAST work out what type of IO is running.
If you want to list out these SLO's complete with expected response times, then run the command.

symcfg list -slo -detail -by_resptime -all

If you have more than one SRP, then you simple add the -srp parameter to select the SRP you want this storage pool to be in. If you want to know what SRPs are defined, use the command

symcfg list -srp

Now you need to add some capacity to your new storage pool. Use the command

symconfigure -sid 038 -cmd "create dev count =10 config=tdev, emulation=fba size=2048 GB sg=app1_sg;" preview

This will add 10 thin devices each of 2048GB in fba emulation. Note that as they are thin devices, they do not use any space initially and will grow up to 2048GB as data is added. Also, we did not need to define any Meta devices!

Now you need to present your data to a host with a masking view by using command

symaccess -sid 038 create view -name app1_mv -sg app1_sg -pg app1_pg -ig app1_ig

If you device later that this storage group needs a higher SLO and at the same time, let FAST analyse the IO and decide the best action to take, then you can change it easily with a command like this:

symsg -sid 038 -sg app1_sg set -slo Gold -wl none

Listing Commands

To get some information about existing SRPs and storage groups, try these commands

symsg list -srp -demand -type slo

This command will give you capacity usage data, detailing how much of your SRP capacity is being used by each of the SLO. It will also give usage data for DSE and Snapshots - more about these later.

Symsg list -by_SLO -detail

This command lists out the storage groups and shows if they are associated with an SLO.

symcfg list -srp –demand -type sg

VMAX data is thin provisioned and so each storage group will have 2 capacities, the amount of space they are actually using and the amount they can potentially grow to. This command will list out both capacities for each storage group. There is also a SnapShot Allocated (GB) Column, which can be used to identify storage groups that are using an excessive amount of snapshot space. So now it is time to talk about snapshots


The DMX3 uses TimeFinder SnapVX, usually just called SnapVX. SnapVX uses Redirect-On-Write (ROW) technology, which is new to TimeFinder. When an update is made to a source track, this update is asynchronously written to a new location in the SRP, and the original data is preserved for the snapshot. Pointers are used to make sure that each copy of the track is used by the correct data. SNAPVX snapshots do not require target volumes and in nocopy mode they will only use extra space when the source volume is changed. A single source volume can have up to 256 snapshots, and these snapshots also save space by sharing point-in-time (PIT) tracks, or 'snapshot deltas'. The snapshot deltas are stored in the SRP alongside the source volume and each snapshot has a set of pointers that reference the set of snapshot deltas that are needed to preserve a PIT image.

Now earlier I suggested that you define a storage group for each application. It is also possible to group storage groups together, so that one parent storage group has a number of associated child storage group. Each child can have its own SLO (and in fact the parent group cannot be associated with an SLO). The beauty of this arrangement is that you can snap entire storage groups, or sets of storage groups with a single command, and the snap by definition will be PIT consistent. You can then define a linked target volume to make this snapshot accessible to a host, which then makes consistent PIT copy of an entire application available for offline backup, or for testing purposes.
If you define your Linked Target Volume to be in Copy Mode, then the snapshot will copy all the data in the background and create a complete set of application data.

So to create a snapshot, you use the symsnapvx establish command. Here, we take a snapshot of our app1_sg storage group, call it daily_snap, and keep it for 7 days.

symsnapvx -sid 038 -nop -sg app1_sg establish -name daily_snap -ttl -delta 7

To access this snapshot, you need to link a host mapped target volume to the snapshot data. The links may be created in Copy mode (by adding -copy after the link command) for a permanent copy of the target volume, or in default Nocopy mode for temporary use.

symsnapvx -sid 038 -sg app1_sg -snapshot_name daily_snap link -lnsg snaptarget

You can restore your original source volume from a snapshot with the symsnapvx restore command

symsnapvx -sid 038 -sg app1_sg -snapshot_name daily_snap restore

If you run the same snap create command twice, SnapVX will create a new snapshot with the same name, but a different generation number. To get some information about your snaps you can try the following command, which will list all existing snapshots, with generation numbers, space used and expiry dates.

symsnapvx -sid 038 list -sg app1_sg -detail

Older VMAX and Symmetrix SYMCLI commands


Before you can do anything with a VMAX, you need to install the Solution enabler software, which you can get from powerlink.emc.com. You download the software, unzip or untar it, run the emc-install program and get the product licensed.
Now you have your software, but you need to run an initialisation command before you can connect to your DMX. Navigate to /usr/symcli/bin and run;

symcfg discover
symcfg list

The first command gets information from the DMX and uses it to build a configuration database on your host. The second command lists that information out.

However symcfg is a very powerful command that can be used to display and alter the configuration of a VMAX. My preference is to use symconfigure for most of this, but symcfg can be used to manage VMAX locks, RDF and director ports, gatekeeper devices, hosts and host ports, mainframe connections, and more.

Discover all VMAX arrays connected to this host, then build or refresh the Symmetrix configuration database file using this information:

symcfg discover

Display information held in the Symmetrix configuration database about all attached Symmetrix arrays

symcfg list

Display more detailed information about the attached Symmetrix arrays and their directors

symcfg list -v -dir all

Display detailed information about a specific director, in this case 0E

symcfg list -v -dir 0E

Display information about all front-end directors on Symmetrix array 824

symcfg list -SA ALL -sid 824

Display information about all the registered hosts that are connected to the Symmetrix array 824

symcfg list -connections -sid 824

To list all gatekeeper and database access locks, enter:

symcfg list -semaphores

To verify whether the Symmetrix 824 configuration and the Symmetrix configuration database are in sync, enter:

symcfg verify -sid 824

list the port flags for port 0 on director 5 position A

symcfg -sid 38 list -sa 5A -p 0 -v

Take the above port offline (necessary to change port flags - and remember this could make storage unavailable to users so use with caution)

symcfg -sid 38 offline -sa 5A -p 0

enable port flag vcm-state on the above port

symcfg -sid 38 set port 5A:0 vcm-state=enable

put the port back online

symcfg -sid 38 online -sa 5A -p 0


The symconfigure command lets you make changes to your Symmetrix device, for example to add new volumes, add or change port and host assignments and configure remote mirroring RDF devices. It updates the symm.bin file on the symm. device. The command cannot be shortened, symcfg is a different command

As part of making changes, symconfigure lets you save the current configuration, reserve devices to prevent others from using them, and gives you a number of query, list and verify options to check the current status of a symmetrix and validate any proposed changes before applying them.

You run symconfigure from a host server that is connected to the symmetrix, If anything happens to that host or the connection to the symm. while a change was in progress then the symm. could be left in an indeterminate state. To cater for this scenario, symconfigure has an abort option that lets you back out uncompleted changes.

symconfigure itself has a fairly small set of parameters, it does most of its powerful processing by reading a command file. The simplest command is symconfigure -h, the online help facility. The other symconfigue commands require a -sid parameter which identifies the Symmetrix that you are going to change. Before you want to start to make changes you will probably want to see your existing Symmetrix configuration.

If the query command shows that a hung session exists, then no more updates will be possible as any session puts a lock 15 on the symm.

Checking VMAX status using symconfigure and managing reserves

These examples commands are running against a VMAX with a symmetrix ID of 123

Query VMAX 123 to see what total freespace is available

symconfigure -sid 123 -freespace -unit mb list

Display the version number of the SYMCLI, SYMAPI and the configuration server. -sid is optional, leave it off and the versions for all attached symms are displayed.

symconfigure -sid 123 -version -v

The query command will check for any existing active configuration activity. If this command cannot get the information, it will keep retrying. You can control this with the -i and -c options which are interval between retries and number of retries.
Query a VMAX 8 times at 5 second intervals to see if any updates are running

symconfigure -sid 123 -i 5 -c 8 -v query

Query a VMAX for reserves

symconfigure -sid 123 -reserved list

Query a given reserve to get more details

symconfigure -sid 123 -reserve-id 4567 show

Safely attempt to release reserve 4567

symconfigure -sid 123 -reserve-id 4567 -noprompt release

Symconfigure examples using the command file

If you are planning updates to your VMAX configuration, then generally the best way to do this is to put all your updates into a command file, then run that file through the symconfigure command. The advantages of doing this is that you can get your commands peer checked by a colleague and syntax checked by the system before you run them. Each command has three options,
'preview' which checks the syntax of your command list;
'prepare', which also checks your syntax, then checks that the VMAX is in a healthy enough state to process the commands, with enough free resources to process the command,
'commit' which does the first two, then applies the updates.

The basic syntax for running symconfigure updates using a command file called command.txt is

symconfigure -sid 123 -v -file command.txt preview
symconfigure -sid 123 -v -file command.txt prepare
symconfigure -sid 123 -v -file command.txt commit

Some optional parameters are -noprompt which suppresses the 'do you really want to ...' messages and -v for verbose which means echo results back to the terminal

Command file examples

Changing devices

Create 2 small Gatekeeper devices. Gatekeepers are used to communicate with the VMAX. EMC recommends 4 gatekeepers per port and they are typically created with just 6 cylinders.

create dev count=2 size=6 emulation=fba;

Create 20 bigger Standard devices

create dev    count=20,

Note that the commands are not case sensitive, parameters can be separated by commas or spaces, can span more than one line, can contain extra white space, but must end with a semicolon ';' .

Add 6 a new spare devices

create spare count=4, format = 520;

Older symmetrix devices has 512 bytes in a block, new devices have 520 bytes in a block.

To delete disks use

delete dev Device-name

Working with Metas

EMC split a physical device into between 1 and 128 hyper volumes, which are then combined together to form meta devices. A meta corresponds to a LUN as presented to a host, so a LUN can be bigger than a physical device. A meta-device can consist of up to 1024 hypers, but all the hypers must be the same size and type and have the same protection. Valid hyper sizes range from between 0.5 and 32GB. A Meta can be concatenated, that is, it can consist of hypers strung together, or it can be striped, when the data is striped across the hypers. The first device in a meta is known as the meta head.

The starting point is to find any unmapped devices using the command symdev list -noport. If any of these devices are allocated as BCV pairs or defined to device groups, then split them out using commands like this

symmir -g group_name split
symmir -g group_name rmall

Examples of symconfigure command files working with metas

define a concatenated meta and add 2 more devices to it. Concatenated metas are best for sequential data access, and they are easier to gorw or shrink that striped metas.

form meta from device 028
add dev 015:016 to meta 028;

define a striped meta and add 2 more devices to it. Striped metas are best for random data access, but they can't be shrunk and are more difficult to grow.

form meta from device 02b
add dev 017:018 to meta 02b;

Split meta 02b back into it's constituent hypers - this will destroy any data on the meta!

dissolve meta dev 02b;

remove device 016 from meta 028

remove dev 016 from meta 028;

Using SYMTIER to work with FAST tiering

Two types of FAST tier exist, disk provisioned virtual tiers and virtual provisioned storage tiers. 'Disk provisioned' is also split into static and dynamic. The following command will list all the storage tiers in array '123', including DiskGroup and Virtual Pool Tiers. If you just wanted to list DiskGroups or Virtual Pools you would add the switch -dp or -vp as appropriate.

symtier -sid 123 list

To get more detailed information about a specific tier use this command - obviously with your subsystem id and tier name.

symtier -sid 124 show -tier_name TEFD1


To work with FAST tiers, you need to be able to create and delete them, and also add and remove disks from them. The following command will create a static, disk provisioned pool called 'TSDP1', configured in RAID5, 3+1 format in disk array '123' from SATA disks. Alternative disk tecnology options are FC (Fiber Channel) or EFD (Enterprise Flash Drive). -dsk_grp is the disk groups to be added to the tier. In this case we are allocating a single disk group ID=2, but you can allocate a list of disk groups, and you can allocate them by name.

symtier -sid 123 create -name TSDP1 -inc_type static -tgt_raid5 -tgt_prot 3+1 -technology SATA -dsk_grp 2

This command will create a flash disk tier in RAID1 format. -vp means this tier will be allocated using virtual provisioning

symtier -sid 123 create -name TEFD1 -tgt_raid1 -technology EFD -vp

To add a disk group to an exisiting tier use the following command. This adds 'disk group 3' to existing Storage Tier 'TSDP1'.

symtier -sid 123 -tier_name TSDP1 add -dsk_grp 3

and to remove it again use

symtier -sid 123 -tier_name TSDP1 remove -dsk_grp 3

You can also rename a tier if you did not like the existing naming standard, so 'TSDP1' becomes 'Tier_qxy29p1'

symtier -sid 123 rename -tier_name TSDP1 -name Tier_qxy29p1

and finally, to delete a tier use this command.

symtier -sid 123 delete -tier_name Tier_qxy29p1

Examples of symconfigure command files for mainframe disks

Create a mainframe striped meta. This must include at least 4 meta devices. This example creates 4 * 500 cylinder metas, then uses them to create a 2000 cylinder striped CKD meta in a RAID1 configuration.

create dev count=4 size=2000
emulation=CKD-3390 config=2-way-mir

PAV aliases are used to allow multiple concurrent access to mainframe devices. See the PAV section for details. The following commands can be used to allocate PAV aliases. The first command will add 4 aliases to a specific symm. device. The second command allocates a range of aliases to a sub system

add pav alias to dev 02b alias count=4
add pav alias range 127:255 to mvs ssid=B000

Some other useful commands


One of the main uses of the symdev command is to see what free hypers are available. The command to do this is

symdev list -noport

symdev list -da all space

symdev list -meta

symdev show meta head address

The second command will show all backend space available
The third command will list out all the meta heads, and also tell you how many hypers are associated with each meta head.
The last command will list out all the details for one meta. The show command usually gives more detail than list, as it reads its information from the host database.


Returns a string with a detailed description of any return code generated by any SYMAPI function
To return a string for error number 10, enter:

symapierr 10

The following will be output:

SYMAPI Error Message: No Symmetrix devices found with microcode version 5x63 or up.


This command checks which devices are mapped to a host
To work out directory and port mappings enter:

syminq -pdevfile

back to top