A storage virtual machine (SVM) is a logical partition of a physical storage system. NetApp’s SVM (formerly vFiler), VMware vSAN, and Ceph pools are all implementations of this pattern. The use case: multi-tenancy - one physical storage system serves many isolated tenants, each with their own volumes, protocols, and access controls. The team that needs to give different teams or customers isolated storage on shared hardware uses SVMs.
Table of contents
- What an SVM is
- NetApp SVM (the original)
- VMware vSAN (the HCI approach)
- Ceph pools (the open-source approach)
- Linux LVM (the cheap approach)
- When to use SVMs vs the alternatives
- How this fits the rest of the stack
- FAQ
What an SVM is
A storage virtual machine partitions a physical storage system into independent virtual storage systems. Each SVM has:
-
Its own volumes (logical units of storage)
-
Its own network interfaces (data LIFs in NetApp terminology)
-
Its own protocols (NFS, SMB/iSCSI, S3)
-
Its own access controls (export policies, share permissions)
-
Its own namespace (the tenant sees only their own volumes, not the other tenants’)
The team that has a 100 TB NetApp filer serving 50 different customers uses SVMs to give each customer their own isolated namespace, on the same physical hardware, with no cross-tenant visibility.
NetApp SVM (the original)
NetApp’s SVM (formerly called vFiler) is the canonical implementation. Each SVM on a NetApp ONTAP cluster:
-
Has its own volumes, qtrees, LUNs
-
Has its own data LIFs (logical interfaces - IP addresses for client access)
-
Exports via NFS, SMB, or iSCSI, with its own export policies and authentication domain
-
Can be moved between cluster nodes without downtime (live motion)
The team that uses NetApp ONTAP for enterprise storage uses SVMs to isolate tenants - different business units, different customers, different environments (dev/staging/prod).
VMware vSAN (the HCI approach)
vSAN is the hyper-converged storage layer in vSphere. Each ESXi host has local disks; vSAN aggregates them into a single distributed datastore.
The multi-tenancy pattern: vSAN datastore is shared across the cluster; vSphere namespaces, resource pools, and storage policies provide isolation per tenant. The team that runs a vSphere cluster with vSAN uses these mechanisms, not SVMs per se.
For multi-tenancy at the storage layer, the team that uses vSphere uses storage policies (SPBM - Storage Policy-Based Management) to assign different performance tiers and replication settings to different VMs.
Ceph pools (the open-source approach)
Ceph pools are the SVM equivalent. Each pool has:
-
Its own placement rules (which OSDs the data lands on)
-
Its own replication setting (replica count, CRUSH rules)
-
Its own quotas (max size, max objects)
-
Its own auth (cephx capabilities per pool)
The team that uses Ceph for storage creates one pool per tenant (or per use case - hot pool, cold pool, backup pool).
Linux LVM (the cheap approach)
On a single Linux host, LVM (Logical Volume Manager) provides a similar pattern:
-
Volume groups (VGs) - partitions of the physical disks
-
Logical volumes (LVs) - the usable storage units
-
The team that wants isolation between services on a single host uses separate LVs for each service’s data.
LVM does not give multi-tenancy in the way NetApp SVMs do (no network isolation, no separate auth), but it gives storage isolation. The team that has multiple databases on one host uses separate LVs to prevent one filling the disk and taking down the others.
When to use SVMs vs the alternatives
SVMs are right when: you have a multi-tenant storage system, each tenant needs its own network identity, volumes, and access controls. The team that has 50 customers on a single NetApp uses SVMs.
SVMs are overkill when: you have a single application with single-tenant storage. The team that has one database on one host does not need an SVM.
The right pick by scale:
-
1-3 tenants, single host: separate LVs, separate mounts.
-
3-20 tenants, single host or small cluster: LVM + a per-tenant user/auth model.
-
20+ tenants, shared enterprise storage: NetApp SVMs, vSphere namespaces, or Ceph pools.
-
100+ tenants, multi-region: a multi-tenant storage service (built on top of any of the above).
FAQ
What is the difference between an SVM and a virtual machine?
A virtual machine is a software-defined computer with its own OS, CPU, memory, and storage. An SVM is a software-defined storage system - no OS, no compute, just storage. The team that uses SVMs partitions storage; the team that uses VMs partitions compute.
Is storage virtualization the same as a storage VM?
Yes - ‘storage virtualization’ is the broader concept; ‘storage VM’ is one implementation. The NetApp SVM, vSAN datastore, and Ceph pool are all storage virtualization.
Can I run an SVM on commodity hardware?
Yes - MinIO, Ceph, and LVM run on commodity hardware. NetApp SVMs require NetApp hardware (or NetApp ONTAP Select on commodity x86, which is the entry-level option).
What is the difference between SVM and a NAS share?
A NAS share is a single export point on a storage system. An SVM is a logical partition that can host multiple shares, with its own network identity and auth. The team that has one NAS share has a single mount target; the team that has an SVM has a multi-tenant namespace.
Do I need SVMs for a small deployment?
No - the team that has 1-3 tenants and a single host uses separate LVs and separate users, not SVMs. SVMs are for the 20+ tenant case.
How this fits the rest of the stack
For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
Useful related references: