Troubleshoot classic deployment issues with creating a new Linux virtual machine in Azure
Important
Classic VMs will be retired on March 1, 2023.
If you use IaaS resources from ASM, please complete your migration by March 1, 2023. We encourage you to make the switch sooner to take advantage of the many feature enhancements in Azure Resource Manager.
For more information, see Migrate your IaaS resources to Azure Resource Manager by March 1, 2023.
When you try to create a new Azure Virtual Machine (VM), the common errors you encounter are provisioning failures or allocation failures.
- A provisioning failure happens when the OS image fails to load either due to incorrect preparatory steps or because of selecting the wrong settings during the image capture from the portal.
- An allocation failure results when the cluster or region either does not have resources available or cannot support the requested VM size.
Important
Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. This article covers using the Classic deployment model. Microsoft recommends that most new deployments use the Resource Manager model. For the Resource Manager version of this article, see here.
If your Azure issue is not addressed in this article, visit the Azure forums on MSDN and Stack Overflow. You can post your issue in these forums, or post to @AzureSupport on Twitter. You also can submit an Azure support request. To submit a support request, on the Azure support page, select Get support.
Collect audit logs
To start troubleshooting, collect the audit logs to identify the error associated with the issue.
In the Azure portal, click Browse > Virtual machines > your Windows virtual machine > Settings > Audit logs.
Issue: Custom image; provisioning errors
Provisioning errors arise if you upload or capture a generalized VM image as a specialized VM image or vice versa. The former will cause a provisioning timeout error and the latter will cause a provisioning failure. To deploy your custom image without errors, you must ensure that the type of the image does not change during the capture process.
The following table lists the possible combinations of generalized and specialized images, the error type you will encounter and what you need to do to fix the errors.
The following table lists the possible upload and capture combinations of Linux generalized and specialized OS images. The combinations that will process without any errors are indicated by a Y, and those that will throw errors are indicated by an N. The causes and resolutions for the different errors you will run into are given below the table.
| OS | Upload spec. | Upload gen. | Capture spec. | Capture gen. |
|---|---|---|---|---|
| Linux gen. | N1 | Y | N3 | Y |
| Linux spec. | Y | N2 | Y | N4 |
Y: If the OS is Linux generalized, and it is uploaded and/or captured with the generalized setting, then there won’t be any errors. Similarly, if the OS is Linux specialized, and it is uploaded and/or captured with the specialized setting, then there won’t be any errors.
Upload Errors:
N1: If the OS is Linux generalized, and it is uploaded as specialized, you will get a provisioning timeout error because the VM is stuck at the provisioning stage.
N2: If the OS is Linux specialized, and it is uploaded as generalized, you will get a provisioning failure error because the new VM is running with the original computer name, username and password.
Resolution:
To resolve both these errors, upload the original VHD, available on-prem, with the same setting as that for the OS (generalized/specialized). To upload as generalized, remember to run -deprovision first. See Create and Upload a Virtual Hard Disk that Contains the Linux Operating System for more information.
Capture Errors:
N3: If the OS is Linux generalized, and it is captured as specialized, you will get a provisioning timeout error because the original VM is not usable as it is marked as generalized.
N4: If the OS is Linux specialized, and it is captured as generalized, you will get a provisioning failure error because the new VM is running with the original computer name, username and password. Also, the original VM is not usable because it is marked as specialized.
Resolution:
To resolve both these errors, delete the current image from the portal, and recapture it from the current VHDs with the same setting as that for the OS (generalized/specialized).
Issue: Custom/ gallery/ marketplace image; allocation failure
This error arises in situations when the new VM request is sent to a cluster that either does not have available free space to accommodate the request, or cannot support the VM size being requested. It is not possible to mix different series of VMs in the same cloud service. So if you want to create a new VM of a different size than what your cloud service can support, the compute request will fail.
Depending on the constraints of the cloud service you use to create the new VM, you might encounter an error caused by one of two situations.
Cause 1: The cloud service is pinned to a specific cluster, or it is linked to an affinity group, and hence pinned to a specific cluster by design. So new compute resource requests in that affinity group are tried in the same cluster where the existing resources are hosted. However, the same cluster may either not support the requested VM size or have insufficient available space, resulting in an allocation error. This is true whether the new resources are created through a new cloud service or through an existing cloud service.
Resolution 1:
- Create a new cloud service and associate it with either a region or a region-based virtual network.
- Create a new VM in the new cloud service. If you get an error when trying to create a new cloud service, either retry at a later time or change the region for the cloud service.
Important
If you were trying to create a new VM in an existing cloud service but couldn’t, and had to create a new cloud service for your new VM, you can choose to consolidate all your VMs in the same cloud service. To do so, delete the VMs in the existing cloud service, and recapture them from their disks in the new cloud service. However, it is important to remember that the new cloud service will have a new name and VIP, so you will need to update these for all the dependencies that currently use this information for the existing cloud service.
Cause 2: The cloud service is associated with a virtual network that is linked to an affinity group, so it is pinned to a specific cluster by design. All new compute resource requests in that affinity group are therefore tried in the same cluster where the existing resources are hosted. However, the same cluster may either not support the requested VM size or have insufficient available space, resulting in an allocation error. This is true whether the new resources are created through a new cloud service or through an existing cloud service.
Resolution 2:
- Create a new regional virtual network.
- Create the new VM in the new virtual network.
- Connect your existing virtual network to the new virtual network. See more about regional virtual networks. Alternatively, you can migrate your affinity-group-based virtual network to a regional virtual network, and then create the new VM.
Next steps
If you encounter issues when you start a stopped Linux VM or resize an existing Linux VM in Azure, see Troubleshoot classic deployment issues with restarting or resizing an existing Linux Virtual Machine in Azure.