Azure IaaS VMs: Managing diagnostics and boot diagnostics

When managing Azure IaaS (infrastructure-as-a-service), it is a priority to understand what is going on with your virtual machines. Microsoft Azure offers two easy-to-enable features, and they have a significant impact on your troubleshooting process. The features are boot diagnostics and diagnostics settings (guest-level). In this article, we are going over the process to enable them using Azure Portal and then PowerShell to automate the process and keep consistency among your VMs.

Managing boot diagnostics

Sometimes it is overlooked, but with some of the new features introduced in Azure around IaaS virtual machines, the use of boot diagnostics became a standard and almost a requirement in organizations of all sizes. For example, the use of the Serial Console feature requires boot diagnostics, which makes it practically a must-have.

We can enable it using Azure Portal, and here’s how. In the desired VM properties, click on boot diagnostics. If it is not enabled, a message saying “boot diagnostics is not configured for this virtual machine” will welcome you. Click on Settings.

In the new blade, click on On, select or create a Storage Account, and click on Save. The result of this operation will be a new container into the specified Storage Account. The name of the new container will use this naming convention: bootdiagnostics-<vmName>-<vmID>, and inside of the container we will have a bitmap file of the last screenshot of the VM.

Note: If you want to script and use the container name, both VM name and VM ID are properties available at the VM level.

Some things to consider when planning your boot diagnostics design and storage to support the feature:

  • Currently, premium storage is not supported by boot diagnostics. There is no reason to pay extra to store bitmap files.
  • It is all about your design, but if you want to keep it simple, use a single Storage Account to manage your boot diagnostics per subscription
  • Storage Account firewall and virtual network is not supported. You must allow All networks
  • You can enforce the use of boot diagnostics as part of your pipeline (if using Azure DevOps or similar tools), Azure policies, or runbooks to make sure that all your infrastructure is compliant.

We can use PowerShell to enable the feature with the following cmdlet. We are using Azure CloudShell, so we can see the changes in near real-time, as depicted in the image below.

Get-AzVM -Name <VMName> | Set-AzVMBootDiagnostic -Enable -StorageAccountName <StorageAccountName> -ResourceGroupName <ResourceGroupName> | Update-AzVM

Experience says that the feature is enabled in a few seconds. However, Microsoft documentation states that it may take up to 10 minutes for the bitmap to show up in the Storage Account.

boot diagnostics

If you are using PowerShell, you may see some opportunities for validation and reporting. Here are a few pieces of code that will help with basic reporting, and you can develop more sophisticated scripts from the examples below.

If you want to check if a single VM has the boot diagnostics feature enable. The following cmdlet can be used.

(Get-AzVM -Name <VMName>).DiagnosticsProfile.BootDiagnostics.Enabled

If you want a complete report of all your VMs and their current status of boot diagnostics, the following code will provide that information.

$VMs = Get-AzVM
ForEach ($vm in $VMs){
    $tmpLine = $VM.Name + " --BootDiagnostics--> " + $VM.DiagnosticsProfile.BootDiagnostics.Enabled
   $tmpLine
}

If you want to list only the VMs that do not have the boot diagnostics feature enable, then run this cmdlet:

Get-AzVM | Where-Object { $_.DiagnosticsProfile.BootDiagnostics.Enabled -eq $False }

Managing Azure VM diagnostics settings

By default, all VMs metrics come from the host (virtualization host), and they have limited visibility inside of a VM. However, they can provide basic metrics, such as CPU, disk and network usage.

To have better visibility of what is going on inside of the VM, an agent installation is required. A VM extension will deploy the Azure diagnostics agent as part of the process. To enable using the portal, click on Enable Guest-level monitoring, and wait a few minutes for the process to complete.

The result of that operation is a new extension called Microsoft.Insights.VMDiagnosticsSettings added to the virtual machine, a new Storage Account created to store the additional information on its Tables (the name for the new Storage Account is the combination of the Resource Group name where the VM is hosted, added by diag string and a random number).

The basic monitoring settings are already in place. However, cloud administrators have complete control to fine-tune all areas of the monitoring to suit their requirements.

Firing up PowerShell

Using PowerShell is not that easy, but at the same time allows consistency and configuration of several resources from a single code.

The first step is to create a Storage Account that will store all the diagnostic settings of your VMs. You could use the same one that you are applying for boot diagnostics or use a separate one. Make sure to take note of the name of the Storage Account because we will need that later on.

The second step is to configure a template. Let’s use the VM that we have just enabled manually and change all the settings that we want (performance counters, logs, you name it).

The next step is to create a template for those settings. Add the VM name and its resource group to the cmdlet below, and the result will be a template.json file with all settings that we defined so far using the Azure Portal.

(Get-AzVmDiagnosticsExtension -VMName <VMName> -ResourceGroupName <ResourcegroupName>).PublicSettings | Out-File template.json

There are two changes that we need to work on the template. First, we need to delete line 2, which defines the Storage Account. Yes, remove that line in its entirety. Second, we need to replace the resourceID (it should now be at line 6) for the string <VMName>. Save the file, and that is going to be applied to all new VMs coming aboard.

We are going to use a small piece of code (three lines). On the first two lines, we will define the VM name and the Storage Account. The third line will read our template.json file, and it will create a new one just for the desired VM that we want to enable Guest-Level Diagnostics. The new file name will use the naming convention template-<VMName>.json.

$VM = Get-AzVM -Name "apvm006"
$StorageAccount = "ap6vmdiag"
(Get-Content ((Get-Location).Path + "\template.json")) -replace ’<VMName>’, $VM.Id | Out-File ("template-" + $VM.Name + ".json") -Force

The last piece of the puzzle is to enable diagnostic settings at the VM level, and we can use the following line of code (make sure to run the lines from the previous section because we need those variables in the current cmdlet).

Set-AzVMDiagnosticsExtension -VMName $VM.Name -ResourceGroupName $VM.ResourceGroupName -DiagnosticsConfigurationPath ("template-" + $VM.Name + ".json") -StorageAccountName $StorageAccount

The process will be the same (agent installation) and after a while, it will return the result of the operation. We can see in the portal that the diagnostic settings is enabled, and the Storage Account is using the one that we defined in the cmdlet.

boot diagnostics

Featured image: Pixabay

2 thoughts on “Azure IaaS VMs: Managing diagnostics and boot diagnostics”

  1. can you give me a script which tells which VM is enabled with get-azvmdiagnosticextentension.
    if VM is enabled with diagnosticsetting then true or else false

Leave a Comment

Your email address will not be published.

Scroll to Top