Surebackup Error “OS did not boot in the allotted time”

First Time SureBackup Configuration

If this is the first time SureBackup is being configured, keep in mind that the default Maximum Allowed Boot Time values may require adjustment to find the right value for each VM in each environment. One suggested method to determine the appropriate Maximum Allowed Boot Time, is to set the value to large number, then run the SureBackup job. If it completes without failures, review how long it took for the SureBackup job to report that stability had been achieved. Using that value, add 5 or so minutes, and set that as the new Maximum Allowed Boot Time.

Existing Functional SureBackup Job Failure

A simple solution to resolve "OS did not boot in the allotted time" is to increase the Maximum Allowed Boot Time to a very high value. This will likely make the error stop occurring, as it will give the VM as much time as it needs to reach a stable state. However, it will mask any subtle on-boot issues that may be occurring or occur in the future. The Maximum Allowed Boot Time serves two purposes, it controls how long SureBackup will wait for the VM to stabilize, and it can help to alert the backup admin of potential on-boot issues that may be affecting the original VM that was backed up.

The best course of action is to adjust the Maximum Allowed Boot Time to a sufficient value for the VMs being tested to boot consistently. The default Maximum Allowed Boot Time values are viable for most environments but may require some adjustment to find the correct value for each VM in each environment.

Troubleshooting Advice 

^{This advice applies to both Windows and Linux VMs}

To troubleshoot the "OS did not boot in the allotted time" error, start the SureBackup job (or Retest the individual VM) and observe the VM being tested. There are two key things to keep an eye on:

• Does the hypervisor show that the guest OS has reported an IP address?
• What is the VM doing during its bootup?

Issues Observed and Recommendations

• If the VM appears to be booting as expected when it exceeds the Maximum Allowed Boot time, adjust the value to allow the machine to boot more time. It is possible that the backup storage performance is low and impacts the boot speed of the VM being tested.
  Veeam KB1285: SureBackup Performance Considerations
• If you observe that the VM is performing pending on-boot tasks during the bootup sequence, these are likely tasks that are due to occur on the next boot of the original production VM. For example:
  • If the VM begins processing Windows Updates, this indicates that the original VM had pending Windows Updates to be installed during the next boot.
  • If the VM begins performing a lengthy check disk, this may indicate that the original VM needs to have a check disk performed.
  A time-consuming on-boot task may prevent the VM from reaching a stable state within the maximum allowed boot time. If these occur, it is advisable to rerun the SureBackup job with a restore point created after the on-boot task on the original VM is resolved. (Reboot the original VM, let it run the pending on boot tasks, rerun the backup job, then try the SureBackup Job again)

Windows VM on VMware Stabilization Issue

In rare cases, during the boot of the VM being tested by SureBackup, the VMware Tools Service may fail to start.

To check if this has occurred, do the following:

1. As the VM begins to be powered on, open a console window to it
2. Observe the boot activity. 
3. If the Windows OS reaches the login screen and the VMware Tools state in the vSphere Client does not show active after 3 minutes, do the following to check if the service has failed to start due to the service start timeout:
   1. Log In to VM that the SureBackup job created via a Console
   2. Open Event Viewer
   3. Select Windows Logs > Application
   4. Filter by Event ID 7000, 7009, 7011
   5. If any events indicate that the VMware Tools Service failed to start due to a  Service Start Timeout, implement the solution in this article on the Production VM, rerun the backup job, and retry the SureBackup job.
      Microsoft Article: A slow service does not start due to timeout error in Windows
      
      Note: As an alternative to making changes to the registry, reconfigure the VMware Tools service on the Production machine to have a startup type of Automatic (Delayed Start).

Linux VM on VMware Stabilization Issues

One of the most common reasons a Linux VM fails "Stabilization by IP" is that it fails to acquire an IP because the MAC address that VMware randomly assigns does not match the MAC address the NIC is hardcoded to expect. To resolve this, either (a) update the configuration within the original VM to prevent it during future restores and SureBackup jobs or (b) assign a static MAC to the vNIC.

VMware KB2002767: Networking does not work in a cloned Linux virtual machine
VMware KB219: Setting a static MAC address for a virtual NIC