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

KB ID: 2048
Product: Veeam Backup & Replication
Published: 2015-06-25
Last Modified: 2022-06-16
Get weekly article updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.

Cheers for trusting us with the spot in your mailbox!

Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest

error icon

Oops! Something went wrong.

Please try again later.

Challenge

A VM being started by SureBackup fails with the error:
OS did not boot in the allotted time

Cause

This error occurs when the VM being Power On by the SureBackup job fails to become stable within the "Maximum allowed boot time" specified in the Application Group settings or the Linked Jobs section.

The SureBackup job determines stabilization using different Stabilization Algorithms. These algorithms are hypervisors specific: VMware Stabilization Algorithm / Hyper-V Stabilization Algorithm. The most commonly used one, "Stabilization by IP," watches the VM as it is Powered On and waits to see if an IP address is reported by the integration services running within the Guest OS (VMware Tools or Hyper-V Integration Services). If an IP fails to be reported to the hypervisor before the "Maximum Allowed Boot Time," the error "OS did not boot in the allotted time" occurs.

Solution

This section assumes the VM being tested had a NIC and guest integration services (VMware Tools or Hyper-V Integration Services) running when it was backed up. If guest integration services were not present when a VM was backed up, SureBackup will not check the IP or Heartbeat status and instead wait the full "Maximum allowed boot time" before further testing.
Retesting a Single VM
To retest a single VM, open the SureBackup Job Statistics window, right-click the VM in the list, and select Start. If the application group has already been powered off by that time, it will be started again. After that, you can open the VM console and perform verification and testing manually.

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

More information

It is important to remember that the purpose of the SureBackup job is to pre-emptively identify potential issues in the event of a disaster recovery scenario. If the SureBackup job demonstrates that a VM has a problem, it is doing what it is designed to do. During initial configuration, some limits and timeouts will have to be tweaked to allow the SureBackup to operate. When the SureBackup job fails in the future, it could mean either there is an issue with the SureBackup job configuration or a problem with the machine that was backed up.
 
Additional SureBackup Resources 
Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.

Spelling error in text

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

Oops! Something went wrong.

Please try again later.

KB Feedback/Suggestion

This form is only for KB Feedback/Suggestions, if you need help with the software open a support case

By submitting, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Verify your email to continue your product download
We've sent a verification code to:
  • Incorrect verification code. Please try again.
An email with a verification code was just sent to
Didn't receive the code? Click to resend in sec
Didn't receive the code? Click to resend
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

error icon

Oops! Something went wrong.

Please try again later.