Cloud Volumes ONTAP: an operator's field guide
Cloud Volumes ONTAP (CVO) is ONTAP software running on cloud compute and block storage in your own AWS, Azure, or Google Cloud account. BlueXP deploys and manages the working environment; the ONTAP CLI remains the right place to inspect SVMs, LIFs, volumes, protocols, capacity, and replication. This guide draws that boundary and gives operators a safe day-two workflow.
The operating model: three control planes
| Plane | Owns | Use it for |
|---|---|---|
| BlueXP | Working environment lifecycle | Deploy, discover, license, add aggregate capacity, orchestrate upgrades, and manage cloud-provider resources. |
| ONTAP | Data services | SVMs, volumes, LIFs, export policies, shares, LUNs, snapshots, QoS, efficiency, EMS, and SnapMirror. |
| Cloud provider | Infrastructure boundary | VPC/VNet, routes, security rules, IAM identities, KMS keys, compute, disks, object storage, and billing. |
A CVO cluster is not the same product as Amazon FSx for NetApp ONTAP, Azure NetApp Files, or Google Cloud NetApp Volumes. With CVO, your account contains the controller resources and you retain more ONTAP control; that also leaves more lifecycle responsibility with your team. See the BlueXP overview for Connector placement and service-level concepts.
Single-node and HA architecture
A single-node working environment has one CVO controller and no storage-controller partner. An HA working environment has two ONTAP nodes and cloud-specific coordination resources. It is designed to keep serving data through a controller fault, but it does not make the surrounding network, identity, DNS, or client path highly available by itself.
- Single node: lower infrastructure footprint; use only where an outage during node or infrastructure failure meets the workload's availability target.
- HA: partner takeover/giveback behavior plus cloud-specific data placement and mediation. The implementation differs across AWS, Azure, and Google Cloud, so never transplant a subnet or route design from another provider.
- Failure domains: availability-zone choices are made at deployment and may constrain later changes. Validate the selected topology in the current provider-specific CVO documentation.
cluster1::> cluster show
cluster1::> system node show
cluster1::> storage failover show
cluster1::> storage failover show-takeover
cluster1::> system health status showOn a single-node system, storage-failover output will not describe a usable HA partner. Do not treat that as a fault without first confirming the deployed topology in BlueXP.
Cloud disks, aggregates, and capacity
CVO presents provider block disks to ONTAP, which builds aggregates and FlexVol volumes on top. ONTAP efficiency can reduce logical consumption, while the provider bills provisioned infrastructure according to its own rules. Keep four numbers separate: client-visible logical data, ONTAP used space, aggregate physical consumption, and cloud-provider provisioned/billed capacity.
cluster1::> storage aggregate show -fields size,available,percent-used,state
cluster1::> storage aggregate show-space
cluster1::> volume show -fields size,available,percent-used,space-guarantee
cluster1::> volume show-footprint
cluster1::> volume efficiency showAdd disks and change the underlying working-environment capacity through BlueXP unless current NetApp guidance explicitly directs otherwise. Directly attaching, detaching, resizing, or deleting controller disks in the cloud console can bypass CVO orchestration and put data availability or supportability at risk.
Networking and access
Plan management, intercluster, and NAS/SAN data paths before deployment. Security-group or firewall rules must match the protocols actually enabled; routes, DNS, MTU, and client-side multipathing are equally important. Publicly exposing ONTAP management or data interfaces is rarely justified—prefer private addressing and controlled administration paths.
cluster1::> network interface show -fields vserver,lif,service-policy,address,home-node,home-port,status-oper
cluster1::> network interface service-policy show
cluster1::> network route show
cluster1::> network port show
cluster1::> vserver services name-service dns show
cluster1::> cluster time-service ntp server showService policies—not a guessed LIF role—tell you which services a LIF can carry. For replication, validate intercluster LIF reachability and peer health using the cluster peering guide. For SAN, follow the host multipathing guide; a cloud route alone is not a supported host configuration.
First-login baseline
Capture a read-only baseline after BlueXP reports the environment healthy. It becomes the comparison set for incidents and post-upgrade validation.
cluster1::> version
cluster1::> cluster identity show
cluster1::> system node show -fields health,eligibility,uptime,model
cluster1::> system health alert show
cluster1::> event log show -severity EMERGENCY,ALERT,ERROR
cluster1::> job show
cluster1::> vserver show
cluster1::> volume show -fields state,style,size,available,percent-used
cluster1::> network interface show -fields status-admin,status-oper,is-home
cluster1::> system node autosupport check showExample values and output columns vary between ONTAP 9.x releases. If a field is unavailable, use show -instance or show -fields ? rather than changing privilege level merely to reproduce a checklist.
Create data services and protection
Once BlueXP has created the system and capacity, ordinary ONTAP workflows apply. The example below creates a thin-provisioned NAS volume, mounts it in the SVM namespace, and assigns a snapshot policy. Substitute verified names and sizing for your environment.
cluster1::> volume create -vserver svm_prod -volume app01 \
-aggregate aggr1 -size 2TB -state online -junction-path /app01 \
-space-guarantee none -snapshot-policy default
cluster1::> volume show -vserver svm_prod -volume app01
cluster1::> volume mount -vserver svm_prod -volume app01 -junction-path /app01If volume create already mounted the volume using -junction-path, the separate volume mount is unnecessary; verify before running it. Then apply the correct NFS export policy, SMB share, or SAN objects—see the NFS, SMB, and iSCSI guides.
# Inspect protection before changing anything
cluster1::> volume snapshot policy show
cluster1::> volume snapshot show -vserver svm_prod -volume app01
cluster1::> snapmirror show -destination-vserver svm_prod
cluster1::> snapmirror show -fields status,healthy,lag-time,last-transfer-end-timestampSnapshots protect against logical mistakes on the same system; they are not a substitute for an independent copy. Use SnapMirror to another failure domain and test recovery. Cloud Backup/BlueXP backup workflows are orchestrated separately; confirm their catalog and retention state in BlueXP as well as the source volume's health.
Changes, upgrades, and shutdowns
- Record health, active jobs, capacity, relationships, and client-path state.
- Make lifecycle changes through BlueXP when they affect compute, disks, licensing, HA topology, or the CVO image.
- Follow the exact version path and prechecks presented for that working environment; do not assume an on-prem image-install workflow is interchangeable.
- Re-run the baseline and test protocol access, replication, AutoSupport, and monitoring.
cluster1::> cluster image show
cluster1::> cluster image show-update-progress
cluster1::> system health alert show
cluster1::> storage failover show
cluster1::> event log show -time >1h -severity EMERGENCY,ALERT,ERRORDo not stop controller VMs from the provider console as a routine cost-saving operation. Use the supported BlueXP shutdown/start workflow for your topology and release. Provider-side actions can leave coordination or disk state inconsistent and may not reduce every attached-resource charge.
Incident triage
| Symptom | ONTAP evidence | Cloud / BlueXP evidence |
|---|---|---|
| Working environment unavailable | system node show, storage failover show, EMS if CLI is reachable | BlueXP timeline, Connector reachability, VM health, routes, security rules |
| Clients cannot mount/connect | LIF operational state, routes, DNS, protocol server/session state | VPC/VNet route tables, security rules, peering/transit path, client DNS |
| Volume nearly full | volume show-space, volume show-footprint, aggregate space | Provider disk/service quota and BlueXP capacity actions |
| Replication lag | snapmirror show, intercluster LIF and peer health, EMS | Inter-region path, egress policy/cost controls, Connector not normally in data path |
| HA takeover not healthy | storage failover show, system health alert show, EMS | Provider instance/disk/mediator resources; open a NetApp case before manual infrastructure edits |
cluster1::> event log show -time >2h
cluster1::> system health alert show -instance
cluster1::> network interface show -fields status-oper,is-home
cluster1::> snapmirror show -fields unhealthy-reason,lag-time
cluster1::> job show -state FailureCVO or a managed service?
| Choose CVO when… | Prefer a managed service when… |
|---|---|
| You need broad ONTAP administrative control and portable ONTAP workflows. | You want the provider to own more controller lifecycle and infrastructure operations. |
| The workload needs a CVO-supported ONTAP feature that the regional managed service does not expose. | The managed service's protocol, capacity, availability, and feature set already meets the requirement. |
| Your team can operate BlueXP, ONTAP, and the cloud infrastructure boundary together. | You want fewer infrastructure objects and a provider-native consumption model. |
There is no universal winner. Compare supported features in the target region, failure domains, recovery design, operational ownership, quotas, and the complete cost model—not just $/GiB. Start with the ONTAP deployment decision guide.