VSphere VM instant recovery to Proxmox - no storages selectable

[mkretzer]

Hello,

currently we are migrating some VMs from VSphere to Proxmox. This works perfectly via normal restore (thanks to 13.1) but fails with instant recovery - when we are in the "chose storage" dialog there is no storage visible at all, no matter if we select a CEPH-backed host or a host with shared FC storage.

Is this currently a limitation when restoring VSphere VMs?

Markus

[david.domask]

Hi Markus,

I don't see any such limitation in the supported workloads or the Storage section of the User Guide specifically relating to VMware VMs, so open a Support Case and let Veeam Support review the situation.

[mkretzer]

Will do!

[jbender81]

Hi,
I noticed the same issue.
We have no file based storage set up to host virtual machines, just for snippets, templates and ISO files.
My assumption is, that instant recovery requires a file based final destination, as itself is probably emulating qcow2 during instant recovery and is not able to migrate to raw.
Was perchance one of the available storages a file based storage?
We had not yet time, to test this assumption.

Cheers
Jörg

[mkretzer]

Hello,

we have no file based storage - this would be a great limitation

Markus

[jbender81]

Hi,
This morning I tested instant recovering a PVE-VM to PVE.
For this I enabled "Disk Image" as content type for the local storage, as this storage available on all nodes anyway. With this I could click through the dialogue, but the actual recovery failed with this:

9/3/2026 8:50:02 AM Failed : Creating VM. Failed to execute the command on the hypervisor. Error output: Sorry, user veeamdep is not allowed to execute '/usr/bin/mkdir -p /var/lib/vz/images/2010' as root on node04.<redacted>. (0:00:03)

The reason is, according to https://www.veeam.com/kb4701 line 13

veeamdep ALL=(root) PASSWD: /usr/bin/mkdir ^-p /mnt/pve/[a-zA-Z0-9_.-]+/images/[0-9]+$

the creation of the VM's directory is only allowed for extra file storages _besides_ local, but not for local itself.

The workaround is evident, but still this should be included in the mentioned KB-article and the restriction on destination should be included into the PVE-IR article.

Cheers
Jörg