Hello,
We’ve recently had to move away from Direct SAN backups as we currently have an open ticket with HPE Nimble regarding an issue affecting that transport mode.
In the meantime, we’ve configured Veeam to use HotAdd transport, which is working well for the majority of our environment.
However, one specific VM refuses to back up via HotAdd.
Environment Summary
-
vSphere environment
-
Backup proxy is a VM within the same cluster
-
HotAdd transport mode (Automatic selection)
-
Fallback to network mode disabled (initially)
-
Veeam account used:
adminaccount@vsphere.local(member ofvsphere.local\Administrators, inherited from Global Permissions) -
No snapshot or consolidation warnings on the VM
-
All hosts in cluster have access to the same datastores
Problem VM Details
-
VM has 11 virtual disks
-
A couple of disks reside on a different datastore
-
Veeam successfully creates the VMware snapshot
-
Failure occurs during HotAdd disk attach
Behaviour Observed
When the job runs:
-
Snapshot creation succeeds
-
Proxy begins mounting disks via HotAdd
-
One disk mounts successfully
-
The remaining disks fail during attach
-
Job aborts
Example error:
23/02/2026 19:58:51 :: Error: Agent: Failed to process method {HotAdd.AttachDisks}: Failed to open VDDK disk [[TIERNAME] SERVERNAME_2.vmdk] ( is read-only mode - [true] )
Logon attempt with parameters:
[VC/ESX: [VCENTRE NAME];
Port: 443;
Login: [ADMINACCOUNT@vsphere.local];
VMX Spec: [moref=vm-688];
Snapshot mor: [snapshot-726303];
Transports: [hotadd];
Read Only: [true]]
VDDK error returned:
VDDK error: 13 (You do not have access rights to this file)
Important Observations
-
Permissions appear correct:
-
VM and datastore permissions are inherited from Global Permissions
-
Account is in
vsphere.local\Administrators -
Other VMs back up fine using same account and proxy
-
-
HotAdd itself is functional (one disk mounts successfully)
-
This does not appear to be a general proxy or RBAC issue
-
Snapshot creation works without issue
Additional Finding
The failing disks are assigned the “Veeam CDP Replication” VM Storage Policy.
We are not using CDP and have no CDP jobs configured in Veeam.
Interestingly:
-
The disk that mounts successfully does not have this storage policy applied.
-
All disks that fail during HotAdd do have the CDP policy applied.
This raises the question of whether ESXi may be attempting to honour the VAIO/CDP filter requirement during VDDK open, even though no active CDP jobs exist.
Current Hypothesis
Since:
-
HotAdd works for at least one disk
-
Permissions are inherited and consistent
-
Other VMs back up successfully
-
Only disks with the CDP policy fail
It appears this may be related to storage policy / VAIO filter handling during disk open rather than a pure permissions issue.
Before removing the CDP storage policy from the VM, I wanted to ask:
-
Has anyone seen VDDK error 13 surface in relation to VM storage policies or VAIO filter requirements?
-
Could a non-compliant or unused CDP policy interfere with HotAdd disk attach?
-
Any other areas I should be checking specific to per-disk failures during HotAdd?
Appreciate any insights.
