Back a few years ago it was not uncommon to see a requirement for VMs to be rebooted when maintenance to apply updates to the underlying host was required, every few months. Fortunately this is now mostly a thing of the past, with most updates now being applied using Azure’s in place upgrade process which just pauses for a few seconds while the VM whilst the host is updated. Up until recently I had not seen a maintenance window that require VM reboots for over a year.
However, there are still some updates that do require maintenance windows to reboot VM’s, and there is one of these coming up starting January 10th 2018 that will impact most users of Azure. Thankfully, the planned update process has improved a lot since the last maintenance Window and we now have some new tools that will help make this less painful.
Previously the updates for a maintenance window where distributed solely by email to the subscription owners and co-admins. Meaning that if you where not in one of these roles you may never know that your machines are going to be rebooted. With Azure Service Health we can now see planned miantenace inside the Azure portal and even setup alerts to be notified when these are going to occur.
You can find planned maintenance under the “Azure Service Health” module in the portal:
Once we enter this blade, we can select the “Planned Maintenance” option and see any events that are coming up, and what they impact. In my environment I have a single event for the 10th January:
If we Select this, we can then view more details about the event:
We can also click on the “Affected Resources” Tab to see a list of the machines that are impacted by this maintenance window. Note that the portal will show you alerts and affected machines for the subscription you have selected, so make sure you select any subscriptions you want to look at.
Now that we know a maintenance Window is coming, we have the option to do something about it. In the old days, when you got a maintenance notification and all you know is that your VM’s would be reboot at some point in that window and often this window was 2-3 days, not very helpful. With the new pre-emptive maintenance feature the notification (as seen above) now gives you a period running up to the maintenance window where you can reboot your VMs and have them move to a already updated host on your own schedule. If you don’t do this before the maintenance Window starts then they will be rebooted for you.
Using this pro-active maintenance option we can schedule the maintenance ourselves and provide our customers or users a much more exact time for the reboot as it is under our control.
The easiest way to start the pre-emptive maintenance is the in the “Planned maintenance” window we look at previously for the notifications. If you look at the “Affected Resources” tab you will see a list of VMs that are impacted, plus their current status (whether they have been updated or not) and the option to start pro-active maintenance now.
Selecting the option to start pre-emptive maintenance takes you to a page that shows you the timescale for the window and what will happen if you do, or do not use the pre-emptive maintenance feature.
When your ready, click the “start maintenance” button to begin. This will begin the process of rebooting and moving your VM. In my experience this has generally taken 5-10 minutes. Once it has complete your VM will now show up in the list with a “completed status”.
You can also view and initiate maintenance through the Virtual Machines Tab. The main page now lists the machines maintenance status, and then clicking on the VM.
Note that in this example one of the machines has the status of “Scheduled” this means that I do not have the option to use pre-emptive maintenance for this machine for some reason, and it will be rebooted by the Azure platform during the maintenance window.
There is currently no option in the portal to apply the maintenance to multiple machines at once, you would need to go through and initiate for each one, which is a bit of a pain. If you want to do it in bulk then the way to do this is going to be through PowerShell, where you can have it loop through a list of VMs and apply the maintenance. This can be achieved by restarting the VM with the “PerformMaintenance” flag
Restart-AzureRmVM -PerformMaintenance -name
If you want to query the status of your VM’s pre-emptive maintenance using PowerShell you can look at the MaintenanceRedeployStatus property of the VM:
If you do not perform pre-emptive maintenance during the allotted window (i.e. before the end of the 9th of Jan) then your VM will be shutdown and restarted by Azure at some point during the maintenance Window. At the moment, for the January 2018 window this is showing a very wide range between the 10th and 21st of Jan, hopefully this will be narrowed down before it occurs, but if you want to maintain control of when this occurs then take advantage of pre-emptive maintenance.