Skip to main content

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 @Jos Meijer  help I was able to execute the code, the job was created and started. After a while, Commvault reported that the job failed with the error message "Unable to modify the VMX file to restore the virtual machine."

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.

Hi @VladimirP !  Generally, when something works fine in the gui, but not the command line, the issue is permissions (almost 100% of the time).

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.


@VladimirP just like @Mike Struening my thinking is in the same direction, so did you access the CommCell console using the same account as the one you used to retrieve the API token?

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.


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.

 


@Mike Struening, @Onno van den Berg  and @Damian Andre 

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 @Jos Meijer  (https://community.commvault.com/commvault-q-a-2/restoring-a-vm-to-another-vmware-vcenter-3959) and only a few parameters are passed in this example. Now I open the Web Control Center, select all the options I wanted to change and export to JSON files. This JSON file has a lot more detail than the example I used.

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.


@VladimirP this will be a tough one to solve on the forums.  Can you open a support case, then share the incident number here?


@Mike Struening I don't have access to the support at the moment, but I will check if we can get access to the support when I get back from vacation. In any case, thanks for the suggestions.


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.


 

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.


Forgot to add the Commvault version in the previous post, we are using::

Version: 11.28.14
Commvault platform release: 2022E


Thanks for sharing @VladimirP !


Error Code: [91:40]
Description: Unable to modify the VMX file for restore of virtual machine

during VM replication periodically daily incremental & synthetic full in month,

commvault ver 11.32.45

we got the error usually in some 2 to 3 VM once in week

@Mike Struening - could you please comments on this this is system created schedule not triggered manually, replicating it from on premise vmware to VMC cloud on Amazon


@Dharmender Mike is not around anymore at Commvault. It is not for nothing that his name displays/contains RETIRED. In addition the case is differently in your situation, so it seems, because you leverage replication, right? 


Reply