VM SureBackup job for vSphere always failed

[albertwt]

Veeam Support - Case # 00741940

Folks,

Can anyone here please assist me in how to set the SureBackup Job so that it doesn't need to wait for a long time before turning on the next VM in the Application Group ?

I've been waiting to start each VM from 600 seconds up to 3600 seconds per VM but it always failed somehow due to the VM cannot be considered by Veeam as booting up. I've checked that I can logged in to the VM but Veeam decalre it as failed thus clearing up the whole SureBackup job.

This has waste my time for the whole day to start and wait for the same job more than 9x in the past 12 hours.

[foggy]

You can use linked backup jobs instead of application group and configure the Process simultaneously up to ... VMs parameter to specify the maximum number of VMs that can be started at the same time.

However, I would rather investigate the reason of why the VM start is not detected (could be VMware Tools issue).

[albertwt]

You can use linked backup jobs instead of application group and configure the Process simultaneously up to ... VMs parameter to specify the maximum number of VMs that can be started at the same time.

However, I would rather investigate the reason of why the VM start is not detected (could be VMware Tools issue).

Foggy,
The VM is starting correctly as I can logged in and see the VM desktop with no issue. it just that Veeam still considering it doesn't boot up properly.

However aside from that, is there any way to specify or force the next available test of the VM rather than waiting for hours or thousand of seconds ?

[nefes]

SureBackup detects booting of VM by:
1. Heartbeat from VMware tools. You can see if they are up and running in VSphere client. If you see that it is not - there should be something with it (too old version, for example).
2. If heartbeat test is passed, IP is detected via same tools and ping test is performed. You could also see IP in VSphere client, if it is not reported by tools - we assume VM is not boot up correctly. We also skip IPv6 and APIPA addresses.
There's also script tests, that are performed only if you select that VM contains specific application (DC, DNS, Exchange etc) in job settings.

If you want to define the reason of such long wait, open job session, select specific VM and look which step takes time. It will help you find out the reason of that problem.

You could also uncheck both heartbeat and ping tests and SureBackup will wait exact time you set up and then continue, but no tests will be performed thus no information on consistency of backed up VM.

[foggy]

The VM is starting correctly as I can logged in and see the VM desktop with no issue. it just that Veeam still considering it doesn't boot up properly.

Correct, Veeam cannot detect that VM successfully boots due to inability to perform heartbeat and/or ping tests, as Nikita has described above. Both tests rely on VMware Tools, that's why I suggested it could be related.

[albertwt]

SureBackup detects booting of VM by:
1. Heartbeat from VMware tools. You can see if they are up and running in VSphere client. If you see that it is not - there should be something with it (too old version, for example).
2. If heartbeat test is passed, IP is detected via same tools and ping test is performed. You could also see IP in VSphere client, if it is not reported by tools - we assume VM is not boot up correctly. We also skip IPv6 and APIPA addresses.
There's also script tests, that are performed only if you select that VM contains specific application (DC, DNS, Exchange etc) in job settings.

If you want to define the reason of such long wait, open job session, select specific VM and look which step takes time. It will help you find out the reason of that problem.

You could also uncheck both heartbeat and ping tests and SureBackup will wait exact time you set up and then continue, but no tests will be performed thus no information on consistency of backed up VM.

Yes, in order to bring all of the VM up and running first I have already
1. Deselected both checkboxes and also adjust the boot time from 600 up to 3600 seconds and also the Application start time from 120 to 480 seconds.
2. Uncheck or remove all of the testing script

but somehow it is still failed. when I set the value to be 7200, it takes too long to prepare the Virtual Lab and then the backup kicks in cancelling all of the VM that are already runing.

[foggy]

Have you checked wether VMware Tools are up-to-date?

[albertwt]

Have you checked wether VMware Tools are up-to-date?

Yes all of my VMs are always up to date and running fine. I don't know why the failure is alwaus due to VM is not boot up during the alloted time.

[foggy]

Then please continue working with your support engineer on defining the reason of the failure to detect successful VM boot.