OK so the way instant recovery works is that the Hypervisor attaches directly to the backup to disk location
- for Hyper-V this uses CIFS
- for Vmware this uses NFS
Once attached to the backup to disk location the Hypervisor then directly mounts the required image files to start the virtual machine via the CIFS or NFS shares (which is why overall performance of an instantly recovered VM may not be as good as the original VM)
- for Hyper-V the mount is against VHD(x) files
- for VMware the mount is against VMDK files
What deduplication does however is a splits the backup sets into chunks and then the comparison between chunks across all your backups allows us to save overall storage space. These chunks are no longer presented as VHD(x) or VMDK files so the process from the Hypervisor to mount the image files cannot directly work.
Note: we are researching the possibility go ways to address this limitation but cannot commit to anything currently
With regards cartridge/detachable devices, I believe that testing showed issues with performance that was bad enough to cause problems (stability of VM that is handled by IRT/corruption of VM content etc.)
As for best practices etc:
There is information in Appendix C (for VMware) and Appendix D (Hyper-V) of the Backup Exec 16 Administrators' Guide
There are also sections in the Hyper-V and Vmware Best Practices docs available in this list
https://www.veritas.com/content/support/en_US/doc-viewer.72686287-129480082-0.index.html
In the above list it may also worth being familiar with the content of the general "Granular Recovery Technology" best practices document as well
