Skip to content

Update slow-vm-start-extensions-troubleshooting.md #1984

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ManishaSinha0410 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update slow-vm-start-extensions-troubleshooting.md #1984

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions support/azure/virtual-machines/windows/slow-vm-start-extensions-troubleshooting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,9 +21,9 @@ Although the Azure VM guest OS is active and working, and the VM can connect suc

## Cause

VM extensions are software components that run inside the VM to enable configuration management, security, monitoring, and other features. VM extensions have a 90-minute provisioning timeout. They must complete their installation or update within that time limit. If an extension doesn't provision within the timeout period, it's marked as failed. The extension isn't retried until the next VM operation that triggers it, such as **Start** or **Redeploy**.
VM extensions are software components that run inside the VM to enable configuration management, security, monitoring, and other features. VM extensions have a 90-minute provisioning timeout. They must complete their installation or update within that time limit. Azure typically does not continuously retry that failed extension immediately; instead, the retry is triggered the next time a VM operation occurs that re-engages extension provisioning such as **Start** or **Redeploy**. This retry behavior can delay completion of the operation until the extension either succeeds or times out again.

If a VM has one or more extensions in a **Failed** state, delays can occur in other VM operations, such as **Start** or **Redeploy**. This issue occurs because the Azure platform tries to provision the failed extensions again before it completes the operation. Therefore, the VMs show a **Starting** status for an extended period.
When an Azure VM has one or more VM extensions stuck in a **Failed** state, you may notice that management operations (for example, Start or Redeploy) take much longer than expected. This happens because the Azure platform treats extension provisioning as part of the overall VM operation workflow. Before the operation can be marked complete, Azure attempts to re-provision any extensions that previously failed. As a result, the VM can remain in a **Starting** or **Updating** status for an extended period even when the guest OS is already running and you may still be able to connect to it.

## More information

Expand Down