Instant restore to ESX, how to control CPU count?

[mikeely]

Was testing the instant restore feature and it seemed to be working well - but then I noticed DRS was migrating a boatload of VMs. Turns out the host I had been backing up has a pair of 32-core CPUs. So the agent restore truncated to 32 and gave the VM 32G of RAM. No wonder DRS pulled the fire alarm.
I retried the process but nowhere do I see an option to customize the hardware to eliminate this issue. Am I missing something?

[Mildur]

Hi Mike,

Have you tried editing the VM configuration before powering it on?

Best,
Fabian

[mikeely]

Fabian,
That's the best I can do but it still powers on to do some conversion process before powering back of and showing up as published.

[Mildur]

Hi Mike,

I re-read your first comment and subject. Is the request about controlling CPU or Memory? Or both.

Can you please elaborate on why you don't want to restore such an agent backup to hardware with the same specs?
I assume that in a restore scenario (Dr, migrate from physical to virtual, ...), the machine should have the same amount of memory as before.

Is this for recovery testing? If so, in a SureBackup job, you can adjust the percentage of memory for the tested machine.

We can discuss internally about implementing something similar for other restore options, but I would first like to understand the use case for recovering a machine with lower hardware specs than the source.

Best,
Fabian

[mikeely]

Fabian,

Thanks for getting back to me. This would primarily be a DR scenario into a constrained environment. I encountered it during testing, but for reasons I don't want to get into here we don't use SureBackup for validating our restores, so yeah. Can't use that feature. Anyhow it would be good to both validate restores and also do DR to constrained environment without causing havoc on the ESX cluster