Provision aggregates and volumes

01Choose placement and policy

1. Inspect aggregate capacity and disk protection. Identify the correct aggregate, storage tier, and performance objective. Estimate logical data growth, snapshot reserve/retention, thin provisioning, and physical free space.
2. Decide volume security style, snapshot policy, autosize and space guarantee. For NAS, choose a unique junction path such as /projects; for SAN, plan LUN containment and host alignment separately.

storage aggregate show
volume show
volume show-space

02Create and validate

1. In System Manager, open Storage > Volumes, select the target SVM, name, size, placement, protocol and protection settings. Confirm the chosen policy before saving.
2. For NFS/SMB, confirm the junction is mounted and the volume or qtree has the intended access policy. For SAN, create the LUN and host mapping as a separate controlled step.
3. Write a test file or present a test LUN from an approved client. Re-check volume and aggregate utilization immediately afterward.

volume show -vserver svm_prod -volume vol_projects
volume show-space -vserver svm_prod -volume vol_projects
storage aggregate show

03Worked CLI example: create the NAS volume

1. Assume svm_prod and aggregate aggr_data already exist and have the capacity and policy approved above. Check the aggregate and SVM first.
2. Create a 2 TiB UNIX-style volume and mount it at /projects. Then inspect the volume state, size, junction and remaining aggregate space. Assign a restrictive export policy before client use.

storage aggregate show -aggregate aggr_data
vserver show -vserver svm_prod
volume create -vserver svm_prod -volume vol_projects -aggregate aggr_data -size 2TB -junction-path /projects -security-style unix
volume show -vserver svm_prod -volume vol_projects
storage aggregate show -aggregate aggr_data

04Establish thresholds

1. Set alerts for volume and aggregate headroom. Record which snapshots or workloads explain expected usage. Review physical used space, not only the logical size displayed to clients.
2. When growing a volume, first confirm aggregate capacity and the effect on other guaranteed volumes.

05Worked capacity plan: distinguish commitment from consumption

The following example deliberately avoids relying on future storage-efficiency savings. It treats active data, expected retained changes and growth as planning inputs. Actual physical accounting must be measured after a pilot because compression, deduplication, clone sharing and workload change patterns alter consumption.

1. Compare the forecast to physical aggregate free space and commitments from other volumes. A 2 TiB thin volume does not reserve or create 2 TiB of physical media. Record its space guarantee and the pool’s overallocation exposure.
2. Separate capacity planning from RAID/local-tier creation. Disk ownership, partitioning, RAID group sizes and supported local-tier layouts are platform-specific. Use the matching hardware/release procedure rather than a universal aggregate-create command.
3. Choose autosize limits based on available capacity and workload policy. An unlimited-looking client namespace must not be interpreted as infinite physical headroom.

06Validate the first workload and record the exit conditions

1. Write an approved representative dataset and capture physical usage before and after. Include a snapshot and change cycle when planning snapshot retention; an empty-volume check cannot estimate changed-block growth.
2. Record volume state, junction or LUN containment, security style, policy, guarantee, autosize limit and protection. Test the actual client identity, not just volume creation.
3. Define who owns expansion and cleanup, what reserve is required and when another pool or hardware expansion becomes necessary. Roll back only the pilot access/configuration if validation fails; preserve any non-disposable data.

volume show-space -vserver svm_prod -volume vol_projects
volume show-footprint -vserver svm_prod -volume vol_projects
storage aggregate show-space -aggregate aggr_data