Skip to main content

Hi all,

We have a customer who needs to restore a large VM (multiple disk and TB’s).

This job runs for days and than ends with Failure Reason: Unable to modify the VMX file for restore of virtual machine nvm-name]. 
Attempt start error: oThe parameter is incorrect., Port passed is not valid.
a0/0]. (W32.87)] 

We did not find out why, but customer would like to see that the disks restored are not automatically deleted. Is there a way in Commvault?

Does the additional setting SkipDeleteVm also apply on “regular” VM restore or only on Virtualize Me?

And would an Service account with no delete be an outcome or does this have to many side effects?

Already my thank in advance.

 

Danny

@Danny , let me look into this for you and see when this takes effect.

For those following along, here is the link tot he Additional Setting:

https://documentation.commvault.com/additionalsetting/details?name=SkipDeleteVm


Hi Danny,

That key is not applicable for regular Full VM restore from VSiDA.

In general, full VM restore has restart ability. its resumes from where it left part of previous attempt. Hence will not delete VM and its files in that. After reaching max attempts and if still fails then VM gets deleted and job fails.

Can you check VM and VMX file accessibility in vSphere client. Also please cross check, free space on destination datastore and disk types used in restore of that VM, if any disk occupying whole space on DS.

If logs over rolled,re-try with fresh job and raise a ticket with CV support with complete logs of VSA proxy to check it in that case.

Regards

Gopinath


One possible work around is to restore the individual VMDK disks by attaching them to an existing VM.  You could then create a shell VM with CPU, NIC and Memand move the restored disks to it.

Regards

Ian


One possible work around is to restore the individual VMDK disks by attaching them to an existing VM.  You could then create a shell VM with CPU, NIC and Memand move the restored disks to it.

Regards

Ian

I was just about to make the same suggestion - restore the VMDKs and attach to existing or dummy VM. You can always restore the VMX as well and try editing it. The error seems to relate to networking (i.e port), so you could delete all the network config and upload / register the VMX without it, and re-attach the disks afterwards.


Reply