+3
I restored a VM from a backup to another VMWare vCenter manually from the Commvault console. Then I tried the same from a PowerShell script using the REST API. Thanks to
Does anyone know why it works fine from the Commvault console and not when the same VM is restored using the REST API? What can I check regarding the error message? I researched this error message on Internet but didn't find any helpful articles.
Best answer by VladimirP
View original
+23
Hi
Are you doing any sort of ‘run as’? Which user is actually running the REST API function? They may lack the permissions that the service account configured in the gui possesses.
+19
one thing to try as well is to perform the recovery from Command Center as it offers the ability to press on the "Equivalent API” function just before submitting the recovery. this function generates your request in JSON format which can be passed to the API.
+23
Unable to modify VMX seems like VMware is rejecting the VMX, which to me might mean that one of the fields passed through is wrong, has strange characters or is otherwise incorrectly formatted. That doesn't really help to solve it but that's my clue.
+3
As for the account, I'm using PowerShell with my domain account, but in the script, I'm passing the Commvaul local account and password. After I get the token from the Commvault REST API, I'm able to start the recovery process. If there an issue with the account it shouldn't get token from Commvailt web service and start the recovery (at least I'm guessing). My VMware DR vCenter is registered with Commvault, so I guess I don't need to specify this account in a REST API call because I did it while adding the hypervisor.
I used an example that was posted thanks to
The strange thing is that the Commvault web service accepts the Recovery REST API, creates and start a job, and then fails. If something is missing as a parameter in the Body, it should refuse my REST API call.
In local Commvault REST API Explorer documentation for function '{{ServerURL}}/v2/vsa/vm/{{vmClientGUID}}/recover' there is not indicate what parameters are mandatory in the body. Anyway, I'll try to use the exported JSON file as the body and see what happens. Thanks for the suggestions.
+23
+3
+19
So in case the recovery job start than I would dig into the logs on the access node and if needed turn on debug logging to see if you can identify the root cause. You could also check https://api.commvault.com for more information around the API call that you are trying to perform. Also please share the version you are running. Might be that there is something specific to the processing of the request by the server running the web console.
+3
We figured out why the job failed. While I was on vacation, my colleagues tried to restore the VM and found that although we specify "inPlaceRestore=false" in the body of the URL, Commvault tries to restore the VM to the source VMware vcenter (VC7-PRD) instead of the target VMware vcenter (VC7-DR) we specify in the body.
Here is our body example:
<Api_VMRestoreReq powerOnVmAfterRestore ="false" passUnconditionalOverride="true" inPlaceRestore="false">
<destinationClient clientName="VC7-DR" />
<destinationInfo>
<vmware esxHost="esxi02" dataStore="DataStore01" resourcePool="/" newName="Restored_VM-01" />
</destinationInfo>
</Api_VMRestoreReq>
So why the job failing is now logical, only we don't understand why it's going into the source vcenter instead to restore VM into the target vcenter.
+3
Forgot to add the Commvault version in the previous post, we are using::
Version: 11.28.14
Commvault platform release: 2022E
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
