Solved

SkipDeleteVm

  • 15 April 2021
  • 4 replies
  • 519 views

Userlevel 1
Badge +6

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 [vm-name]. 
Attempt start error: [The parameter is incorrect., Port passed is not valid.
[0/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

icon

Best answer by Gopinath 15 April 2021, 21:45

View original

4 replies

Userlevel 7
Badge +23

@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

Userlevel 5
Badge +8

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

Badge +1

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

Userlevel 7
Badge +23

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