Setting Up Veeam v13 with Nutanix AHV: A Complete Integration Guide

Why This Integration Changed the Game

If you've been running Nutanix AHV in your environment for any length of time, you know the backup story used to be painful. You either deployed Veeam's standalone Nutanix appliance product separately, with its own interface, its own management headaches, or you ran agents inside guests and accepted all the compromise that comes with that. Neither felt right.

Starting with Veeam v12.2, that changed. Nutanix AHV support was folded directly into Veeam Backup & Replication as a native plug-in, which means you can protect your AHV workloads from the same VBR console you use for everything else. VMware, Hyper-V, Proxmox, Nutanix, all in one place. That's the direction the product has been heading, and v13 continues to mature it.

This guide walks you through the complete setup, from verifying the plug-in is installed to running your first backup job. I've kept it accurate to what actually happens in the v13 interface and the current Veeam help center documentation, because I know people use these posts as actual deployment references. Let's get into it.

How It All Fits Together

Before you touch a single wizard, it helps to understand the architecture. The Veeam Plug-in for Nutanix AHV introduces a component called a worker: a lightweight Linux-based VM that gets deployed directly onto your Nutanix cluster. Workers are the workhorses of the data path. When a backup job runs, the worker reads the VM data from the AHV host using Nutanix's native snapshot mechanism and ships it to your backup repository over the network. The backup server itself coordinates the job; it doesn't carry the data.

The plug-in supports two deployment scenarios and it's important to pick the right one upfront:

• Prism Central deployment: if you have Prism Central managing multiple AHV clusters, this is what you want. You add a single Prism Central connection to VBR, and all the clusters registered under it become available. Workers can be distributed across any of those clusters.
• Standalone cluster deployment: if you don't have Prism Central, or you want to treat each cluster independently, you add each Prism Element cluster directly. Backup and restore operations for each cluster are managed separately.

The backup server communicates with Prism Central (or Prism Element for standalone) over HTTPS on port 9440. Workers communicate back to the backup server on port 10006 by default. Veeam automatically configures the required firewall rules on the workers themselves, but you need to make sure your network allows that traffic.

Before You Start: Requirements and Gotchas

Let's talk prerequisites. Get these right before you open the wizard or you'll waste time backtracking.

A Word on Licensing

This trips up a lot of people, so let's be direct about it. Nutanix AHV workloads require Veeam Universal License (VUL). It's instance-based, each protected VM consumes one instance from your pool. This is true even if your existing Veeam environment runs on socket-based licensing for VMware or Hyper-V. Those socket licenses do not cover AHV workloads.

If you're already on VUL across the board, you're fine. Just make sure you have enough instances. If you're still on socket-based licensing and Nutanix is new territory for you, talk to your Veeam rep before you start. Running the AHV integration against a socket-only license will put you in overutilization.

Step 1: Verify the Plug-In Is Installed

The Veeam Plug-in for Nutanix AHV ships as part of the standard v13 installation package. In most cases it's already there, but it's worth confirming before you go looking for options that don't exist yet.

Step 2: Configure Your Backup Repository

Before adding Nutanix to the picture, make sure you have a backup repository configured and accessible from where your workers will live. The workers are what ship data to the repository, so network path and performance between your Nutanix cluster and the repository matter a lot.

A few things to know about repository compatibility with the AHV plug-in:

• Standard repositories (Windows, Linux, CIFS shares, deduplication appliances) all work as targets for backup jobs.
• Cloud Connect and HPE Cloud Bank Storage repositories are not supported as primary backup job targets for AHV. You can use them for backup copy jobs and for Instant Recovery, but not as the direct job target.
• If you migrate a standalone repository to a Scale-Out Backup Repository after the fact, any existing AHV backup jobs pointing to that repository will fail. Editing the jobs to point to the SOBR fixes it. Just plan the transition so you don't get surprised mid-job.
• Use repository-level encryption for your AHV backups. Job-level encryption is not supported for the AHV plug-in. Set your encryption password at the repository instead.

If you already have a repository configured that meets these requirements, you're ready to move on.

Step 3: Add the Nutanix AHV Server to VBR

This is where the integration actually begins. You're registering either your Prism Central instance or a standalone Prism Element cluster with VBR so it can discover your VMs and manage data protection tasks.

Step 4: Deploy Worker VMs

Workers are what make backups actually run. They're lightweight Linux VMs that Veeam deploys and manages automatically on your Nutanix hosts. You need at least one worker per cluster, and for any serious workload, you want workers distributed across nodes so backup traffic doesn't bottleneck through a single host.

Step 5: Create a Backup Job

With the infrastructure side configured, it's time to create a backup job. The workflow feels familiar if you've created Veeam jobs before. Same wizard structure, just scoped to AHV objects.

Step 6: Verify and Monitor

A backup job that runs without errors isn't automatically a good backup. Take a few minutes to confirm the results are what you expect.

After the first job run, check the following in the VBR console under Home → Last 24 Hours:

• Job status: should be Success or Warning. Not Failed. Warnings are common on first runs and usually point to missing workers for some VMs or guest credential issues. Read them.
• Processing speed: hover over the job in the session list to see average throughput. If it's unexpectedly low, check which worker processed each VM, you may have a worker that's too far from its VMs network-wise.
• Restore point count in Backups → Disk: verify that restore points for your protected VMs are showing up as expected.

For ongoing monitoring, configure email notifications under Options → E-mail Settings at the global VBR level. You want to know about failures before your users do.

Optionally, run a SureBackup job against your AHV backups if you have a Virtual Lab configured. This verifies the backup is actually bootable and not just that the file was written. For critical workloads, this step belongs in your regular verification cadence, not just post-setup.

Known Limitations Worth Knowing

Veeam is upfront about these in the release notes, but I want to call them out plainly so they don't bite you in production:

• IPv6 is not supported for AHV backup infrastructure. All components must communicate over IPv4.
• Volume groups with CHAP authentication are not processed by the plug-in. If a VM has CHAP-protected volume groups attached, those disks won't be backed up.
• Volume groups without CHAP are backed up, but crash-inconsistently. The VM snapshot is taken but attached volume groups result in crash-consistent state only. Not application-consistent. Know your workloads.
• Backup Copy exclusions don't apply to Nutanix AHV backup copy jobs. Plan your copy job scope accordingly.
• Cross-cluster VM migration statistics are not tracked. When a VM is migrated between clusters using Nutanix's Migrate Across Clusters feature, Veeam does not track geographic data migration details in job statistics. iSCSI disks mounted to a VM at the time of migration are automatically skipped during backup processing. Category-based jobs are more resilient here. A migrated VM that remains in a protected category will start a new backup chain on the destination cluster automatically.
• Standalone → SOBR repository migration breaks existing AHV jobs until you re-point them. Plan this change during a maintenance window.
• File-level restore is the only restore type available for AHV backups stored on HPE Cloud Bank Storage. Full VM restore and Instant Recovery require other repository types.

Closing Thoughts

The Nutanix AHV integration in Veeam v13 is genuinely mature. It's not a bolt-on anymore. It feels like a first-class citizen in the platform alongside VMware and Hyper-V. The worker model makes sense architecturally, the Prism Central support massively simplifies multi-cluster management, and having everything under one console is the right answer for shops running mixed hypervisor estates.

The things that will trip you up are almost always in the prerequisites: iSCSI Data Services not configured, licensing mismatch, IPv6 in the network path, or workers missing from some clusters. Get those right before the first job run and the setup is actually pretty clean.

If you're running this in a production environment and hitting something I haven't covered here, the Veeam Helpcenter AHV documentation is accurate and well-maintained. It's one of the better vendor doc sets out there. And as always, if something in this guide needs correcting, reach out.