OS Provisioned Failed for Azure VM

Anand, Rishabh (ext) (SMO NAM RI EN STC ATS B) 0 Reputation points
2026-09-29T14:55:12.99+00:00

There have been multiple times that VM had provisioning state shown as Failed.I tried multiple times to recover it by deallocating and restarting it. Although deallocation completed successfully, the VM repeatedly fails to start Up and running and threw an error stating it can't be retrieved, OS seems to get corrupted. I created a snapshot of the disk and will create and check if the new VM from the recovered snapshot works. The newly created VM works good with the recovered snapshot.

Help me to identify what can be the root cause for failing and how to prevent next time OS Provisioned Failed issues.

Azure Virtual Machines
Azure Virtual Machines

An Azure service that is used to provision Windows and Linux virtual machines.

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-09-29T14:55:35.59+00:00

    The most likely root causes, based on the failure pattern described, are these:

    1. Image preparation or OS provisioning problem A common cause of OSProvisioningClientError or OS provisioning timeout is that the source image was not properly prepared or generalized before VM creation. Microsoft documents this specifically for both restore point failures and new VM deployment failures. Typical symptoms include the VM staying in Creating for a long time, then failing provisioning, or repeatedly showing provisioning errors after restart.
    2. Guest agent or extension failure Azure Backup and restore point troubleshooting guidance shows that snapshot and provisioning-related failures can occur when:
      • the VM agent is unresponsive,
      • the Linux agent is out of date,
      • snapshot status cannot be retrieved,
      • an extension is in a failed state,
      • the VM remains in a failed provisioning state because an extension failure interfered with normal operation.
    3. Snapshot/restore-point communication issues Microsoft also documents failures where the platform cannot communicate with the VM agent for snapshot status, or cannot retrieve snapshot status at all. That aligns with the error described that the VM state or snapshot status could not be retrieved.

    Since the VM created from the snapshot works correctly, that strongly suggests the disk data was recoverable and the issue was likely tied to the original VM’s provisioning state, guest agent/extension health, or the original image preparation rather than permanent data loss in the OS disk.

    To help prevent this next time:

    1. Check extension health first In Azure portal > VM > Settings > Extensions > Extensions status, verify all extensions are in Provisioning succeeded. If any extension is failed, resolve that first because failed extensions can put the VM into failed provisioning state and interfere with startup and backup-related operations.
    2. Verify the VM is not stuck in updating/provisioning failure If the VM provisioning state is Updating or Failed, retry operations only after the VM is healthy. Microsoft notes that these states can interfere with backup and related VM operations.
    3. Validate the guest agent For Windows VMs, confirm the agent is installed and responsive. For Linux VMs, confirm the agent is current. Agent problems are a documented cause of snapshot and restore-point failures.
    4. Review whether the original image was properly prepared If the VM was created from a custom image, verify that image preparation was done correctly. Microsoft specifically calls out OS provisioning failures when the image was not properly prepared or generalized.
    5. Collect activity logs when the issue happens For recurring provisioning failures, start with Azure activity logs and deployment operations to identify the exact failing operation and whether the failure is tied to deployment, provisioning, or extension state.
    6. Keep a recovery path ready The snapshot-based recovery used here is a valid recovery path. Microsoft recommends taking a snapshot of the OS disk, creating a disk from the snapshot, and then using that disk for repair or recovery scenarios. Note: disk swap and repair actions can affect VM bootability, so keeping a snapshot first is the safest approach.

    A practical root-cause summary for this case is:

    • Most likely: guest agent or extension failure causing the VM to enter failed provisioning state.
    • Also possible: custom image preparation/generalization issue if the VM originated from a custom image.
    • Less likely but relevant: snapshot-status retrieval or restore-point communication failure.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.