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 5, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
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
dependsOnordering. - 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
statusMessageto 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
locationand 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.idagainst 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
westeuropeattempts to use disk created in another region). - -Validate deployment ordering for child resources (example: VM create begins before disk copy operation reaches
Succeeded).
Seen in Production
Golden image pipeline rotates disks and invalidates static deployment variables
Frequency: common
Example: Production rollout fails because template still references yesterday's OS disk ID.
Fix: Resolve current disk ID from image release metadata during deployment.
Cross-subscription migration left automation targeting old scope
Frequency: rare
Example: VM deployment in new subscription still points to disk resource ID in old subscription.
Fix: Parameterize subscription/resource-group scope and validate it in preflight checks.
Debugging Tools
- -ARM deployment operations and
statusMessagedetails - -az disk show / az resource show
- -Azure Activity Log for disk lifecycle events
- -Azure Resource Graph scope and ID validation queries
How to Verify the Fix
- -Re-run the VM deployment and confirm no
VMOSDiskNotFoundevents appear in deployment operations. - -Check VM instance view to confirm provisioning reaches
Succeededand 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.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.