## TL;DR
A restored VM that boots slowly in a sandbox usually waits on network identity, missing integration services, or drivers hunting for absent hardware, while the agent waits on a fixed timer. Instrument the boot stages, wait for a real readiness signal such as guest tools reporting or a service port answering, fix the slowest stage in the test image, and set the timeout from measured boots.

```text
agent timed out waiting for VM boot in the sandbox and the restore test failed
```

## Use this when
- Restore tests fail at waiting for VM boot although the VM boots minutes later.
- Boot is fast on production hardware and slow only in the sandbox.
- Timeouts cluster on images with many services or pending updates.

## Not for this skill when
- The VM never boots at all and blue screens. Restore image problem.
- The sandbox never finishes provisioning. Earlier stage.

## Steps
1. Boot the restored VM manually in the sandbox and time each stage to the readiness point the test needs. Verify: stage timings are recorded
2. Identify the waiting stage: firmware, OS start, network wait, update processing, or service start. Verify: the dominant delay is named
3. Switch the agent wait from a fixed sleep to polling a readiness signal with a generous ceiling. Verify: the agent proceeds as soon as the VM is actually ready
4. Fix the root delay in the test path, such as detaching absent devices, pre-completing updates in the source backup window, or adding integration services. Verify: a repeat boot is measurably faster
5. Run the restore test suite and confirm boot timeouts clear. Verify: tests pass the boot stage consistently

## Variant phrasings
### vm boot slow sandbox restore test readiness
The readiness phrasing.
### restored vm takes long to boot timeout agent
The duration variant.
### guest tools heartbeat wait restore verification
The signal wording.

Compatibility: Restore verification on VMware and Hyper-V sandboxes with guest integration services, Windows and Linux restored images.

## Why it happens
Restored systems boot into unfamiliar virtual hardware, no production network neighbours, and sometimes a backlog of pending updates or service retries against unreachable domain services. Each wait is individually bounded but they stack past an agent timer set from production boot times. Readiness polling fixes the measurement; removing sandbox-specific waits fixes the cause.

## Edge cases / pitfalls
- A VM waiting for a domain controller in an isolated sandbox will always burn its full network timeout. Isolate with that in mind or provide stub services.
- First boot after restore does one-time work. Judge boot times from the second boot if the test allows it.
- Pending Windows updates during backup windows make restore boots unpredictable. Coordinate patch and backup schedules.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_p4sFdCNJnz-XMPPm-IYMYQ