VMOSDiskNotFound
Azure returns `VMOSDiskNotFound` when a VM deployment references an OS managed disk identifier that cannot be resolved in the active scope.
Last reviewed: February 12, 2026|Editorial standard: source-backed technical guidance
What Does VM OS Disk Not Found Mean?
VM creation or update stops before compute provisioning, so workloads stay unavailable until the deployment can resolve the intended OS disk.
Common Causes
- -Template points to a managed disk ID that was deleted, moved, or never created.
- -Deployment runs in a different subscription/resource group than the managed disk resource.
- -VM location or zone does not match the source OS disk placement constraints.
- -Automation cached an old disk ID after image/snapshot lifecycle changes.
How to Fix VM OS Disk Not Found
- 1Resolve the exact managed disk resource ID from Azure inventory and update deployment input.
- 2Confirm VM scope (subscription/resource group) and region are compatible with that OS disk.
- 3Create missing disk dependencies first, then run VM deployment with explicit `dependsOn` ordering.
- 4Redeploy and verify ARM operation details no longer report OS disk lookup failure.
Step-by-Step Diagnosis for VM OS Disk Not Found
- 1Inspect deployment operation `statusMessage` to capture the exact OS disk ID Azure failed to resolve.
- 2Query the disk directly with CLI or Resource Graph and confirm it exists in the expected scope.
- 3Compare VM `location` and zone settings against the managed disk metadata and source snapshot/image lineage.
- 4Review activity logs for delete/move/rename events that invalidated previously stored disk IDs.
Managed Disk Identity Validation
- -Audit `osDisk.managedDisk.id` against the current disk inventory (example: template still references `/subscriptions/old-sub/resourceGroups/rg-old/providers/Microsoft.Compute/disks/osdisk-prod`).
- -Trace image or snapshot pipelines that regenerate disks with new IDs (example: nightly image refresh replaced source disk but deployment variables kept stale ID).
Placement and Dependency Checks
- -Inspect location and zone compatibility before attach (example: VM in `westeurope` attempts to use disk created in another region).
- -Validate deployment ordering for child resources (example: VM create begins before disk copy operation reaches `Succeeded`).
How to Verify the Fix
- -Re-run the VM deployment and confirm no `VMOSDiskNotFound` events appear in deployment operations.
- -Check VM instance view to confirm provisioning reaches `Succeeded` and OS disk is attached.
- -Execute a boot/readiness probe to validate workload startup from the corrected OS disk.
How to Prevent Recurrence
- -Generate disk IDs at deploy time from authoritative discovery instead of hardcoded static values.
- -Add CI checks that verify referenced managed disks exist in target subscription/resource group before rollout.
- -Use immutable image promotion workflows to avoid accidental source-disk replacement drift.
Pro Tip
- -emit the final resolved OS disk resource ID into deployment outputs and compare it against CMDB records in post-deploy gates.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
500 Internal Server Error vs 502 Bad Gateway: Root Cause
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Playbook
API Timeout Playbook (502 / 504 / DEADLINE_EXCEEDED)
Use this playbook to separate invalid upstream responses from upstream wait expiration and deadline exhaustion, and apply timeout budgets, safe retries, and circuit-breaker controls safely.
Playbook
Availability and Dependency Playbook (500 / 503 / ServiceUnavailable)
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.