Regularizing volume creation for your environment in Veritas Storage Foundation 5.1
Veritas Storage Foundation 5.1 introduced some nice changes into the vxassist utility to support rudimentary allocation templates and volume attribute persistence.  Support for these will allow environments running SF to start regularizing some of their operations related to volume-level provisioning.  For example, you can standardize layouts of volumes created to support production databases versus development, or you can enable or disable stretch clustering based on some volume type name which could be centered on the name of an application that the volume might be created for.

These new changes are in stark contrast to the much more sophisticated ISP (Intelligent Storage Provisioning) template language that was added in 4.0 but that was dropped in 5.1.  ISP was a large scale structural change that in the end just proved too complex.  Instead, the new changes simply extend traditional vxassist functionality and syntax with rule files and the ability to remember and modify allocation time parameters.

To illustrate, consider a common volume allocation request:

     vxassist make myvol1 100g mirror=enclosure logtype=dco

This command will create a 100 gigabyte volume, mirror that volume between enclosures, and create an FMR3 recovery log.

One thing that it didn't do was remember what you had specified.

Certain configuration parameters (number of mirrors, number of stripes, most volume-level features) are remembered because they are fundamental to the volume's configuration state.  However, policies such as "mirror=enclosure" are promptly forgotten.  VxVM will remember that the volume was mirrored (a fundamental state), but will forget the "enclosure" as the mirror separation policy.  As a result, on a volume grow, move, or add mirror operation, to preserve the full "mirror=enclosure" policy, you have to resupply it on the command line:

     vxassist growby myvol1 50g mirror=enclosure

First, let's explain persistency.  VxVM can now be told to remember these non-fundamental "policy" parameters by requesting "persistence" as an attribute:

     vxassist make myvol1 100g mirror=enclosure nlog=2 persist=yes

With that one addition, grow, move, and add mirror operations will automatically include the original policy parameters for subsequent operations.  Thus:

     vxassist growby myvol1 50g

will do the "correct" thing.  If you want, you can discard or replace these rules if they prove too cumbersome:

     vxassist growby myvol1 50g persist=discard


     vxassist growby myvol1 50g mirror=controller persist=update

With that out of the way, we can get to the other new capability: templates.  You can now create the /etc/default/vxsf_rules to store named sets of vxassist attributes.  A few attributes were added to support persistence and descriptions, but otherwise, the attributes are the same as those that vxassist has always supported.  Here is an example /etc/default/vxsf_rules file:

        volume rule basic {
                description="Common rule for all volumes"
        volume rule protected {
                description="Protected volumes"
                rule=basic mirror=enclosure nlog=2
        volume rule performant {
                description="Performant volumes"
                rule=basic layout=stripe

This lists three simple rules.  The first is intended to be used as a core "class" for all other rules.  It specifies that all volumes should support a DCO type log for FMR3-style snapshots and mirror recovery, and specifies that any non-fundamental policies given in the allocation should be remembered.  The second two rules create a 'protected' rule which creates volumes mirrored between enclosures, and a 'performant' rule which creates striped volumes.  With that, to create a 'protected' volume, use the command:

     vxassist make myvol1 100g rule=protected

This volume can be grown or moved, and mirrors can be added, all of which will preserve separation by enclosure.  All such volumes are created with an FMR-3 style DCO.

Right now, the only way to list saved attributes is using the command 'vxlist volume volume-name' which will list all volume tags, including those that were added to support attribute persistency.  For example, for the above volume, there would be an output section that looks like:

        TY   NAME
        tag  vxvm.attr.mirror_3Denclosure

The '_3D' part encodes the '=' character as embedded hexadecimal for the corresponding ASCII.  This will be prettied up in an upcoming release.

     Ronald S. Karr
     Symantec Distinguished Engineer