Share via

"Installing extensions on virtual machine..." does not complete on Azure VM

  • Article

[Update 11/11/2014] The VM agent no longer relies on the VM's configured DNS server for name resolution, so an invalid DNS setting should no longer cause this issue. If you continue to see Installing Extensions when creating a VM or a portal status of Running (Installing Extensions) at any point after the VM is created, that means the status of one or more VM agent extensions on the VM is something other than Ready. In other words, if an extension is returning a status of NotReady, Unresponsive, Installing, or Unknown, that will cause the VM's portal status to show Running (Installing Extensions) .

The simplest way to try resolving that is to delete the extension, and add it back. You can do this from the preview portal by going to Browse Virtual Machines, select the VM, select Extensions, select the extension to remove and click Delete. After it has been deleted, go back and select Add and add it back.

To check the status of extensions in Azure PowerShell you can run:

(Get-AzureVM -ServiceName <cloud service name> -Name <VM name>).ResourceExtensionStatusList

For example (in this case the cloud service and VM name happen to be the same):

 (Get-AzureVM -ServiceName clnov8ws12r2a -Name clnov8ws12r2a).ResourceExtensionStatusList
 
 HandlerName : Microsoft.Azure.Security.IaaSAntimalware
 Version : 1.1.0.0
 Status : Ready
 Code :
 Message :
 FormattedMessage :
 ExtensionSettingStatus : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.ResourceExtensionConfigurationStatus
 ExtensionData :
 
 HandlerName : Microsoft.Compute.BGInfo
 Version : 1.1
 Status : Ready
 Code :
 Message :
 FormattedMessage : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.GuestAgentFormattedMessage
 ExtensionSettingStatus :
 ExtensionData :

To check the status of the VM agent itself, look at the GuestAgentStatus property instead of ResourceExtensionStatusList:

 (Get-AzureVM -ServiceName clnov8ws12r2a -Name clnov8ws12r2a).GuestAgentStatus 
 
 ProtocolVersion : 1.0
 TimestampUtc : 11/11/2014 7:13:41 AM
 GuestAgentVersion : 2.4.1198.689
 Status : Ready
 Code :
 Message :
 FormattedMessage : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.GuestAgentFormattedMessage
 ExtensionData :

 ==========================================

When creating a VM you may see that although provisioning completes successfully and the VM reaches the Running state, Installing extensions on virtual machine... does not complete.

This may occur if internet name resolution is not working in the VM, which can be a result of invalid DNS settings on a virtual network or the DNS server itself not resolving internet addresses. Internet name resolution is necessary for the VM agent to download the VM agent extension files from Azure storage as well as to report VM health.

Note that the VM may be accessible (for example via RDP with a remote desktop connection) because provisioning has completed successfully, but the VM agent has not been able to install extensions (for example, the BGInfo extension that is installed by default on Windows VMs to display VM details on the desktop background wallpaper).

When viewing the GuestAgentStatus with Azure PowerShell, you may see GuestAgentVersion is Unknown and Status is NotReady.

(Get-AzureVM -ServiceName cljun18ws12r2a -Name cljun18ws12r2a).GuestAgentStatus | Format-List GuestAgentVersion,Status

GuestAgentVersion: Unknown
Status : NotReady

Looking at the C:\WindowsAzure\Logs\WaAppAgent.log file in the VM may show the following as evidence of the name resolution issue:

Writing the aggregate status file to blob storage failed with error: The remote name could not be resolved: '<storageaccountname>.blob.core.windows.net'

If the VM was deployed into a virtual network, check the DNS settings on the virtual network to make sure the DNS servers you are specifying are correct and able to provide name resolution. You can also specify a public DNS service as a test to confirm if name resolution is the issue.

If the VM was not deployed to a virtual network, the VM will be given DNS settings from Azure's internal DNS service. In that scenario it is unlikely that the extensions would fail to install for this reason.

Comments

  • Anonymous
    July 23, 2014
    In my case, I could not access the VM via ssh, which means I could not check the information you mentioned. How can I figure out how to fix this? Thanks!

  • Anonymous
    August 18, 2014
    Jane confirm that you connect at correct public port of the VM you are connecting to. I saw similar issue when I added my VM to the CloudService that had other VM in it with endpoint set up on public port 22, as a result my new VM got public endpoint set to some random port.

  • Anonymous
    October 13, 2014
    There should be default storage account since VHD files will be stored as blob over there. try Get-AzureSubscription -current | Set-AzureSubscription -CurrentStorageAccountName $storageaccountname. If you dont have storage account then you need to create it