Moving off VMware: ONTAP with Proxmox VE and other hypervisors

What survives the move

• All NAS/SAN protocols: NFS, SMB, iSCSI, and FC are plain standards — a Proxmox host mounts an NFS export or discovers an iSCSI LUN exactly like any other client.
• ONTAP data services: snapshots, FlexClone, SnapMirror, QoS, encryption, and storage efficiency live in the array, not the hypervisor. They keep working with zero changes.
• SVM/volume configuration: export policies, igroups, LUN maps, shares, and security styles are all client-agnostic.
• Management plane: System Manager, the ONTAP CLI, and REST APIs don't care what hypervisor mounts the storage.

NetApp is also investing in the non-VMware ecosystem — e.g. the Nutanix + ONTAP integration work covered on the NetApp blog. Check the current integrations list before assuming any given ecosystem is unmanaged.

What you lose leaving VMware

Note: none of this is a storage problem — it's an orchestration gap. Plan for it before the move; the storage layer keeps behaving like ONTAP always has.

Path 1 — NFS with nconnect (the default for most workloads)

NFS is the simplest Proxmox-to-ONTAP path: create an NFS volume, add an export rule, and add the datastore in the Proxmox UI (Datacenter → Storage → Add → NFS). For throughput, tune the Linux NFS client.

# ONTAP side: make sure the SVM has data LIFs and an export rule for the subnet
vserver nfs show -vserver vs1
network interface show -role data -vserver vs1
vserver export-policy rule create -vserver vs1 -policyname default \
  -protocol nfs -clientmatch 10.10.0.0/16 -rorule sys -rwrule sys -superuser sys

# Proxmox host: mount with nconnect to open multiple TCP connections per mount
mount -t nfs -o rw,hard,nconnect=8,vers=4.1 10.10.0.10:/vol_proxmox /mnt/vol_proxmox

# /etc/fstab entry (persistent)
10.10.0.10:/vol_proxmox /mnt/vol_proxmox nfs rw,hard,nconnect=8,vers=4.1 0 0

• nconnect: the Linux NFS client opens up to 16 TCP connections per mount (set with nconnect=N), spreading a single mount across multiple connections — a well-known fix for single-flow NFS throughput limits against ONTAP. Values of 4–8 are a common starting point; test with your workload.
• NFSv4.1: preferred over v3 for locking, sessions, and later features. Match vers to what the SVM's NFS server allows (vserver nfs show).
• Export rule gotcha: the default export policy has no access rule — NFS mounts fail with permission denied until you add one (see the NFS troubleshooting guide).
• Balance LIFs: for heavy multi-host workloads, spread client mounts across several data LIFs so no single LIF saturates; ONTAP NFS also does per-connection load balancing in later releases.

Path 2 — iSCSI with multipath (for block workloads)

Proxmox's LVM-iSCSI storage type presents iSCSI LUNs to VMs as block devices. ONTAP supports ALUA, so multipath hosts can route through both nodes of an HA pair and fail over without disruption.

# ONTAP side: enable iSCSI on the SVM, create a LUN, map it to the Proxmox host
vserver iscsi create -vserver vs1
lun create -vserver vs1 -volume vol_block -lun /vol/vol_block/lun0 -size 2t -ostype linux
igroup create -vserver vs1 -igroup proxmox1 -protocol iscsi \
  -initiator iqn.2026-01.com.example:proxmox1
lun map -vserver vs1 -path /vol/vol_block/lun0 -igroup proxmox1 -lun-id 0

# Proxmox host: discover and log in to both node LIFs
iscsiadm -m discovery -t sendtargets -p 10.10.0.11
iscsiadm -m discovery -t sendtargets -p 10.10.0.12
iscsiadm -m node -T iqn.2026-01.com.netapp:vs1.lun0 -p 10.10.0.11 --login
iscsiadm -m node -T iqn.2026-01.com.netapp:vs1.lun0 -p 10.10.0.12 --login

# /etc/multipath.conf — let dm-multipath honor ONTAP's ALUA path priorities
devices {
  device {
    vendor                  "NETAPP"
    product                 "LUN"
    path_grouping_policy    group_by_prio
    path_selector           "service-time 0"
    failback                immediate
    no_path_retry           queue
  }
}
# after login: verify multipath sees both paths
multipath -ll

• Two LIFs, both nodes: log into the data LIFs on both HA nodes (ideally with iSCSI session multiplexing enabled on the SVM) so multipath has an active + standby path per ALUA.
• Verify sessions: iscsi session show -vserver vs1 on ONTAP shows each host's sessions; multipath -ll on the host shows active/standby per path.
• Queuing on path loss: no_path_retry queue (or a bounded retry) prevents immediate I/O errors during a takeover; the same is standard practice for any ONTAP block client.
• For databases/VMs on block: iSCSI on Proxmox is the closest analog to your old VMFS/RDM setups — expect the same LUN-sizing and multipath discipline to apply.

What about Fibre Channel?

If you're moving an AFF with FC ports to Proxmox, the honest answer is: Proxmox VE ships no native FC storage plugin (as of Proxmox VE 8.x), so FC LUNs aren't a first-class datastore type the way they are in ESXi. Practical paths:

• iSCSI over the same fabric: ONTAP serves iSCSI on any IP network — use the FC-capable networking you already have, or dedicated iSCSI VLANs, and skip FC entirely.
• NFS datastores: the simplest path, and what most Proxmox + ONTAP shops run in production.
• FC via gateway/VM: some environments pass FC HBAs through to a VM running a target daemon, or front LUNs with an iSCSI target — both add a supportability question mark; treat them as homelab territory, not something to bet production on.

Note: if you were relying on ONTAP FC target mode specifically, confirm current Proxmox FC support in the Proxmox storage wiki before committing — this area changes over time. The safe default is NFS or iSCSI.

Backups and DR without SnapCenter

You lose the hypervisor-aware snapshot orchestration, so rebuild the story from the array side — ONTAP snapshots are still the fastest recovery point:

• Array snapshots + NFS restore: schedule ONTAP snapshots per volume (snapshot policy), and restore a crashed VM's files by mounting the snapshot via the .snapshot directory or volume snapshot restore. This is the same workflow as any NFS client — see the snapshots deep-dive.
• Proxmox Backup Server (PBS): the native Proxmox backup path — VM-level incremental backups with deduplication, independent of the array. Pair PBS for VM-level restores with ONTAP snapshots for fast volume-level recovery.
• Veeam agent/standalone: Veeam can protect Proxmox VMs via agent-based backups (guest-level) — you lose the array-snapshot integration, but keep the rest of the platform.
• DR runbooks, not SRM: with SnapMirror or MetroCluster underneath, write a scripted failover: quiesce, snapmirror update / switchover, mount the destination volume to the DR Proxmox cluster, start VMs. It's manual orchestration where SRM was automatic — document it and rehearse it.
• NDMP/tape: unchanged from any ONTAP environment — see the port reference for NDMP ports if you keep tape in the mix.

Gotchas that bite

• Default export policy blocks everything: add your Proxmox subnets to an export rule or mounts fail with permission denied even with correct credentials.
• NFS over a single flow: without nconnect, a single mount may cap out well below array capability — measure with dd/fio before blaming ONTAP.
• iSCSI without multipath: a single-session LUN dies on takeover; multipath + ALUA is the difference between a blip and an outage. Confirm multipath -ll shows both paths before going live.
• Security style for mixed access: NFS (Unix) + SMB (NTFS) access to the same volume needs a mixed security style and identity mapping — see the NFSv4 ACL migration guide.
• SnapCenter/Veeam expectations: old backup jobs and replication policies referencing VMware constructs will silently fail or need rework — audit them before cutover, not after.
• ONTAP Select on Proxmox: running ONTAP Select under Proxmox is not supported — it boots, but there's no support path. Use physical FAS/AFF or a supported cloud option instead.

Migration checklist

1. Inventory VMware-integration dependencies: VASA/VVols, SRM, SnapCenter jobs, Veeam storage-integration repos.
2. Decide the storage path per workload: NFS (default) vs iSCSI multipath (block/DB) vs SMB (Windows guests).
3. On ONTAP: create SVM volumes, export rules / LUNs + igroups, snapshot policies, and (for DR) SnapMirror relationships.
4. On Proxmox: add NFS/iSCSI storage, configure nconnect mounts or multipath.conf, verify multipath -ll.
5. Benchmark: fio/dd over NFS and iSCSI; compare against your pre-move numbers.
6. Set up backups: PBS repositories + ONTAP snapshot schedules; test a restore end-to-end.
7. Migrate workloads (Proxmox storage migration or guest-level copy), then decommission VMware datastores.
8. Write and rehearse the DR runbook (snapmirror update/switchover → mount → start VMs).
9. Update monitoring: ONTAP alerts (event), snapshot health, multipath status.