Contant timeout deploying windows VM's

[lovettchris]

Describe the bug

We have a custom windows image that our team deploys regularly, and every time it times out "OS Provisioning for VM 'sr-test-08' did not finish in the allotted time". This confuses the team, is there any way to stop this from happening?

Related command

az deployment group create ...

Errors

{"status":"Failed","error":{"code":"DeploymentFailed","target":"/subscriptions/0533c3bf-0d48-47d3-8002-7d58f1ff38f0/resourceGroups/GCRIaaSLoanT4p2/providers/Microsoft.Resources/deployments/gamevm_deployment_windows11_template","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.","details":[{"code":"ResourceDeploymentFailure","target":"/subscriptions/0533c3bf-0d48-47d3-8002-7d58f1ff38f0/resourceGroups/GCRIaaSLoanT4p2/providers/Microsoft.Compute/virtualMachines/sr-test-08","message":"The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'.","details":[{"code":"OSProvisioningClientError","message":"OS Provisioning for VM 'sr-test-08' did not finish in the allotted time. However, the VM guest agent was detected running. This suggests the guest OS has not been properly prepared to be used as a VM image (with CreateOption=FromImage). To resolve this issue, either use the VHD as is with CreateOption=Attach or prepare it properly for use as an image:\r\n * Instructions for Windows: https://azure.microsoft.com/documentation/articles/virtual-machines-windows-upload-image/ \r\n * Instructions for Linux: https://azure.microsoft.com/documentation/articles/virtual-machines-linux-capture-image/ "}]}]}}

Issue script & Debug output

see above

Expected behavior

Provide a better error message explaining how to fix it. The info about attaching from a VHD does not work for us, we need to create VM's from image gallery with new hard disks every time. Is there a timeout parameter somewhere?

Environment Summary

azure-cli 2.55.0 *

core 2.55.0 *
telemetry 1.1.0

Extensions:
account 0.2.5
azure-devops 0.26.0
bastion 0.2.5
ssh 2.0.2
storage-preview 1.0.0b1

Dependencies:
msal 1.24.0b2
azure-mgmt-resource 23.1.0b2

Python location 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\clovett.REDMOND.azure\cliextensions'

Python (Windows) 3.11.5 (tags/v3.11.5:cce6ba9, Aug 24 2023, 14:38:34) [MSC v.1936 64 bit (AMD64)]

Additional context

No response

[azure-client-tools-bot-prd]

Hi @lovettchris,

2.55.0 is not the latest Azure CLI(2.61.0).

If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

[azure-client-tools-bot-prd]

Hi @lovettchris
Find similar issue #20510.

Issue title	AKS cluster creation using ARM template is failing with timeout exception
Create time	2021-11-25
Comment number	2

---

Please confirm if this resolves your issue.

[yonzhan]

Thank you for opening this issue, we will look into it.

[lovettchris]

I may have found a solution, I am no longer using the image gallery and instead I'm using "az snapshot create" to create a snapshot of my golden VM, then using "az disk create" to create a new disk from this snapshot, then using "az vm create" to "attach" to this disk, then the above errors go away. So it seems image gallery really doesn't like using ungeneralized images...but I really need to use ungeneralized images that have my local user all setup and ready to go when I stamp out my new VMs....

[torreymicrosoft]

Thanks for your patience, @lovettchris — this was picked up as an outstanding open issue for the ARM Deployments team to review, and thanks especially for circling back in December with what you found.

Your own follow-up nailed it: the image-gallery path expects generalized images, and an ungeneralized custom image (one with your local user already set up) hits OS-provisioning that never "completes," which surfaces as the did not finish in the allotted time error. Your workaround — az snapshot create → az disk create → az vm create attaching that disk — is exactly the right pattern for ungeneralized golden images, because attaching a managed disk skips the from-image OS-provisioning step entirely.

On the two asks:

• There isn't a deployment-level "provisioning timeout" knob to extend — the OS-provisioning timeout is a Compute/VM-agent behavior, not something az deployment controls.
• The error wording (and the suggestion to generalize vs. attach) is owned by the Compute/VM provider, so that's where any message improvement would land.

Since this is Compute provisioning behavior rather than a CLI/ARM deployment bug, and you've already got a working approach, I'd suggest closing this out. I'll close this out and redirect it proactively in-case of reopen to the Compute folks.