After analyzing the results of creating a virtual machine in Micosoft Azure without planning it, I created a plan and had a look how it works.
Well, to be honest, not everything worked as planned (surprisingly, as my plans usually work out well 😉 ), but in the end the result is very close to what I expected, even though the way to reach the goal was not as straight as I thought.
Note: This post is part of a series of postings describing several aspects I found noticeable or good to know when I recently created a virtual machine in Microsoft Azure. “Notes and Observations when setting up a Virtual Machine in Microsoft Azure” gives an overview of all parts of the series.
Preparation
Of course, I followed my own suggestions on what to do before creating a virtual machine in Azure. I stepped thru the upfront activities and had a look at the points to regard.
Following these suggestions, I did the following before I created any resource:
- Defined naming conventions
- Defined resource group structure
- Defined the network requirements
- Defined the minimum number of resource groups
- Optimized disk size and number
- Was clear about VM size and performance requirements
Planned Resources
Following my list of minimum required elements for Microsoft Azure VMs, I created the resources. Due to some dependencies, in the following sequence:
- Resource Group
- Virtual Network
- Network Security Group (required by Network Interface)
- Network Interface
- Public IP Address, added it to the network interface, and deleted the “ipconfig1” address
- Storage Account with connectivity method “Public endpoint (selected networks)” (tab “Networking” of the creation wizard) and disabled public blob access (tab “Advanced”)
As the default name of the subnet of the virtual network default does not follow my naming conventions, I renamed it by clicking on its name when I created the virtual network (tab “IP Addresses”). As you can see from the screenshot below, no services were selected for service endpoint policies at that point in time.
When setting the connectivity method of the storage account to “Public endpoint (selected networks)”, new fields show up in the wizard to define the virtual network that is allowed to access the storage account. After selecting the previously created virtual network, it is required to define the subnets which will be able to access the storage account. Selecting the subnet, the portal informs that the “Microsoft.Storage” endpoint will be added to it.
Having these things done, I thought I am ready and complete to create the virtual machine from a backup of a test VM I created previously. To no surprise, restoring the VM was not the end of the story…
Undesired additional Resources
Creating a virtual machine from a backup via the portal gives you the opportunity to set the target resource group, virtual network, subnet, and staging location. Unfortunately, it is not possible to set the network interface and the public IP address. So, instead of using my already created resources, the portal created a new network interface and a new public IP address – without even giving me the chance to define its names to follow my naming conventions 🙁
Use my Resources
To make the VM use my resources, which follow my naming conventions, I had to attach my network interface and detach the one created by the portal.
As long as the virtual machine was running, the “Attach network interface” button of the network settings of the VM was disabled. Deallocating the VM enabled the button. But still I was not able to attach my network interface. The following error occurred:
Failed to attach network interface ‘network-interface-name‘ to virtual machine ‘vm-name‘. Error: The Resource ‘Microsoft.Compute/virtualMachines/vm-name‘ under resource group ‘resource-group-name‘ was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix
The link named in the error message was not really helpful in my case. Checking the resources, the VM was there and accessible (I already deallocated it). So it seems to my like the error message was misleading.
Looking at the network interface that was created by the portal, I noticed that it was not connected to a network security group, which means that the access to my virtual machine was not controlled! Bad thing for a VM having a public IP! Accordingly, I set the network security group of the interface to my group.
To my surprise, having this completed, I was able to attach my network interface to the VM too! Don’t know if it was just a timing issue or related to the not-matching network security group setting of the network interfaces.
Being happy to have my network interface attached to the VM, I detached the created one and deleted both this interface and the public IP address, that was created when restoring the VM.
Missing Resources
After replacing the generated resources I noticed that I was not able to access the VM via RDP, backup was missing, and no auto-shutdown was scheduled. This lead to the following additional resources:
- Inbound Security Rule to allow RDP access for specific IP addresses
- Recovery Service Vault for backup purposes (changed storage replication type and soft delete settings when creating it)
- Backup Policy to follow my naming conventions (renamed it from default “DailyBackup” to follow my conventions when enabling VM backup)
- Additional Resource Group, created by Azure, required to store the instant recovery points of managed virtual machines; I was able to set the name according to my conventions
When creating the vault, the portal recommends to review the default properties of the vault before protecting items. As you can see from above, I did so 😉
Luckily, the name of the additional resource group required for backup can be customized.
Hidden Types
Also showing the hidden types of the two resource groups, three more resources were found:
- microsoft.compute/restorepointcollections (only record in the backup resource group)
- microsoft.compute/virtualmachines/extensions for the monitoring agent of the virtual machine
- microsoft.devtestlab/schedules schedule for auto-shutdown
Summary
Not so bad I think. There are only two resource groups created, the resources follow my naming conventions (as far as possible, not the disk), and when I want to delete the VM and everything related to it, I just have to delete these two resource groups.
I’ve learned a few things about the right order when creating resources, and how to replace those created by the portal with the ones I created.
Links
Notes and Observations when setting up a Virtual Machine in Microsoft Azure
Upfront Activities before creating Virtual Machines in Microsoft Azure
Things I will regard when I create my next VM in Microsoft Azure
Minimum required Elements for Microsoft Azure VMs