Update slow-vm-start-extensions-troubleshooting.md #1984
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Updating cause section: Updating cause section: 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. 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.
|
@ManishaSinha0410 : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
Contributor
|
Learn Build status updates of commit 8a20b30: ✅ Validation status: passed
For more details, please refer to the build report. |
Contributor
Author
|
Hello @JarrettRenshaw, |
Collaborator
|
#sign-off - Ross pls create a CI for this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updating cause section:
Updating cause section:
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.
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.
Pull request guidance
Thank you for submitting your contribution to our support content! Our team works closely with subject matter experts in CSS and PMs in the product group to review all content requests to ensure technical accuracy and the best customer experience. This process can sometimes take one or more days, so we greatly appreciate your patience.
We also need your help in order to process your request as soon as possible:
We won't act on your pull request (PR) until you type "#sign-off" in a new comment in your pull request (PR) to indicate that your changes are complete.
After you sign off in your PR, the article will be tech reviewed by the PM or SME if it has more than minor changes. Once the article is approved, it will undergo a final editing pass before being merged.