VMware restore fails with “Failed to add VM to target server's inventory” but when we look at the subtext of the failure within the binary log we see “Failed to find VirtualMachineConfigInfo” and this represents the root of the failure.
Below are two examples of the restore failure using VMware plugin 2.1.55 and 2.1.58
VMware Plugin 2.155 failure:
Job Message 2012/09/28 15:50:15 1407 Data Plugin HRFBKPSERVER Plug-in for VMware 2.1.55 restore
Error 2012/09/28 15:51:36 1407 Data Plugin HRFBKPSERVER
VMWVIM :08188 592 0 155136 Copied 16484 bytes
VMWVIM :08188 433 0 155136 DOM: Read XML failed
VMWVIM :08188 520 0 155136 Failed to remove default devices
VMWVIM :08188 526 0 155136 Failed to find VirtualMachineConfigInfo
VMware Plugin 2.158 failure:
Job Message 2012/10/09 10:36:02 1408 Data Plugin HRFBKPSERVER Plug-in for VMware 2.1.58 restore
Error 2012/10/09 10:36:28 1408 Data Plugin HRFBKPSERVER Failed to add VM to target server's inventory
MWRESTR:07340 406 0 103628 Skip creating folder for disk file '[vdi_02_vm5_vv] F1TFS/F1TFS_1.vmdk'
VMWVIM :07340 520 0 103628 Failed to remove default devices
VMWVIM :07340 526 0 103628 Failed to find VirtualMachineConfigInfo
We have identified the conditions that trigger the error:
1. Error happens only with vSphere 5 servers.
2. Error happens only with VMs with big configurations, i.e. their configuration information exceeds certain limit.
The cause of the issue seems to be that with vSphere 5, VMware started using "HTTP Chunked Transfer Encoding". When VMware plugin was tested it with an earlier version of vSphere and chunked transfer does not appear in this version. Hence the issue was not seen until the release of vSphere 5
upgrade to VMware plugin 2.1.80
As an alternative you could restore to files and use VMware converter to restore the VM. If you chose this method of restore I suggest reading the following solution before attempting the restore.
See the Resolution of the solution as You will need to need to modify the VMX file for the restore to work, as the VMDK files will have different names to that seen in the VMX file. This is because during backup we store the VMDK files in chunks therefore creating multiple VMDK files for each original VMDK file. This means that the original VMX file does not reflect the correct VMDK file configuration for restore. When restoring using NetVault this does not matter because we create a new VMX file during restore but when restoring from files we restore the original VMX file which has the wrong VMDK configuration.
Solution URL:
https://support.quest.com/SolutionDetail.aspx?id=SOL81488
