Storage Admin Hub
All guides/Configuration
Configuration · Worked procedure

Create an SVM and data network

A protocol-ready storage VM with correct data LIF placement.

By Hrishikesh NaikUpdated 3 min read
Scope

AFF/FAS NAS SVM and Ethernet LIF example · SAN design differs

Scenario

Example: SVM svm_prod serves NFS on VLAN 220 through two data LIFs. An SVM is the administrative and protocol boundary for volumes and client access.

About the command and output examples

Names, addresses and results are illustrative. Commands have not been executed against a live storage system or SAN switch for this publication. Confirm syntax and compatibility for your release, then rehearse in an approved lab. Existing-data recovery and destructive changes need an environment-specific plan. Read the editorial standards.

01Design the service

  1. List protocols, SVM name, IPspace/broadcast domain, VLAN, LIF IPs, subnet/gateway, DNS and directory services. Map data LIFs to nodes and ports with redundancy.
  2. Confirm physical switch VLANs, MTU, routing, and firewall rules. For SAN, use the protocol-specific LIF and host design rather than assuming NAS failover behavior.
Acceptance check

Approved worksheet with one row per LIF, home node/port, address, role, and target switch.

02Configure in System Manager

  1. Open Storage > Storage VMs and add a storage VM. Select the required protocol(s), root volume placement, security style, and administrative settings.
  2. Create data interfaces on the planned ports or VLANs and enter approved IP settings. Configure SVM DNS/name services, then enable protocol services only after prerequisite servers respond.
  3. Create a small test volume or LUN after the protocol is ready. Do not expose it broadly; validate with a test client or host.
Read-only validation 
vserver show
network interface show
network port show
network route show

03Troubleshoot reachability

  1. If clients cannot reach the SVM, compare DNS answer to the data LIF address, check LIF operational status and current port, VLAN tagging and switch port, route, and firewall.
  2. If name-service operations fail, check SVM DNS, NTP, LDAP/AD reachability, and the relevant protocol logs before changing the service.
Acceptance check

Each intended data LIF responds from its client network and appears on the expected port.

04Make the network design auditable

Two addresses do not establish redundancy when both depend on one switch or when a LIF has no reachable eligible failover port. Record physical network failure domains and compare the LIF’s permitted failover targets with ports carrying the same client VLAN. A broadcast domain describes reachability assumptions; it does not configure an upstream switch for you.

Example row format; the actual VLAN, subnet and failover targets come from the network design
LIFHome placementAddressPurpose
lif_nfs_01Node 1 / approved VLAN port192.0.2.30Client data; use a NAS service policy
lif_nfs_02Node 2 / approved VLAN port192.0.2.31Second planned client endpoint
SVM management if usedApproved administration networkSeparate approved addressAdministrative API/SSH access as designed
  1. Inspect VLAN/port membership, link state and MTU on ONTAP and the upstream switch. Confirm the client route and return path. Use a consistent MTU supported along the entire path instead of setting jumbo frames on storage alone.
  2. Check SVM routes and name-service configuration. Test from an actual client subnet, not only from a machine on the local storage network.
  3. Follow the release-specific System Manager flow to create the SVM and LIFs. Then compare current placement with home placement and document the intended failover behavior.

05Worked reachability distinction and pilot acceptance

Illustrative case: clients on the local subnet can access .30, but routed clients time out. The LIF is up and the export is unchanged. Check the SVM return route and network policy for the routed source; altering NFS permissions would not address the timeout. In a second case, routed connections work and NFS is denied, which directs the next check to protocol/path authorization.

Read-only network comparison 
network interface show -vserver svm_prod
network route show -vserver svm_prod
network port broadcast-domain show
vserver services name-service dns show -vserver svm_prod
Acceptance check

A permitted client from each intended subnet can reach the correct protocol endpoint. The pilot records current/home placement, failure domains and service validation.

Continue learning

Use the section links to revisit a step, or follow a related guide below.

Official references and further reading

Choose the matching release in the vendor documentation before using a command or design. References open on the publisher’s website; linked material remains with its publisher.