After creating the Azure virtual machine having the features backup, recovery, and antimalware protection by just clicking in the portal, plus doing a site failover test and site failover, I ended up with an unexpected high number of resources.
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.
List of Resources
Here is what I found. And just in case: before publishing this post, all resources were deleted. 😉
|AzureBackupRG_location_1||Resource Group||Contains hidden microsoft.compute/restorepointcollections of the virtual machines configured to have backup, one restorepointcollection per virtual machine|
|NetworkWatcherRG||Resource Group||Contains hidden microsoft.network/networkwatchers, one per location used for my virtual machine; to be precisely two, one for the primary location, one for the recovery location; according to Microsoft’s docs on resource groups, this group can be ignored, as “… it’s created automatically to enable Network Watcher in Azure virtual networks.” (see Principles of Resource Groups)|
|Site-recovery-vault-rg||Resource Group||contains storage account, automation account, and service vault for recovery; storage account to my surprise is not in the recovery location, but the source location|
|VM-Test||Resource Group||Contains the VM itself, its public ip address, network security group, network interface, VM’s data disk, VM’s OS disk, storage account for boot diagnostics, recovery services vault (another than in resource group Site-recovery-vault-rg, and a virtual network|
|vm-test-asr||Resource Group||Contains the VM’s OS replication disk, VM’s data replication disk, replication virtual network, replication network interface, replication virtual machine, and two hidden virtual machine extenstions for monitoring and site recovery|
|crpj1dsiterecovasrcache||Storage Account||Contains containers (in my case 7, see below) used for replication / recovery plus one log container|
|testvmsaprocc||Storage Account||Contains the boot diagnostics container and a log container|
|First-VM||Virtual Machine||The virtual machine itself|
|First-VM-ip||Public IP Address||Public ip address of the VM|
|First-VM-nsg||Network Security Group||Defines network access rules to access the virtual machine, seven rules defined on creation|
|first-vm924||Network Interface||The network interface of the VM|
|first-vm924||Network Interface||The recovery network interface of the VM, unfortunately having the same name like the source network interface, but located in a different location and resource group|
|First-VM_DataDisk_0||Disk||VM’s disk for user application and data|
|First-VM_DataDisk_0-ASRReplica||Disk||Data disk for VM replication|
|First-VM_OsDisk_1_guid||Disk||VM’s OS disk|
|First-VM_OsDisk_1_guid-ASRReplica||Disk||OS disk for VM replication|
|site-reco-30u-asr-automationaccount||Automation Account||Contains schedules for site recovery|
|vault942-yxu-asr-automationaccount||Automation Account||Also contains schedules for site recovery|
|Site-recovery-vault-location||Recovery Service Vault||Defines items to be backup up and / or replicated, only contains the backup of the replicated VM|
|vault942||Recovery Service Vault||Defines items to be backup up and / or replicated, contains the backup of the source VM|
|vault942||Recovery Service Vault||Defines items to be backup up and / or replicated, contains the replication of the source VM; is member of a different resource group, can’t recall why|
|testvmsa||Storage Account||Contains the VM’s boot diagnostic blob containers|
|VM-Test-vnet||Virtual Network||The VM’s virtual network|
|VM-Test-vnet -asr||Virtual Network||The VM’s recovery virtual network|
Storage Account Containers for Replication / Recovery
In case Azure Site Recovery / Replication is enabled for a virtual machine, replication creates several containers within the configured cache storage account. From what I saw, the number of containers seems to be somehow connected to the number of disks of the VM. But there is no 1:1 relationship. For my virtual machine having the OS, temporary and data disk (overall three), seven containers were created. Having a VM with OS and temp disk only, I found five cache containers.
I was not able to find any connection from a container to the virtual machine. This means, in case one storage account is used to keep the replication containers of multiple VMs, it is impossible to say which container belongs to which VM. This is a serious problem when one, but not all, of the VMs should be deleted. Which containers has to be deleted then?
For test purposes, I deleted all while the VM was running. Deleting them was not a problem. To no surprise, replication had some issues then. I had to manually resync the VM.
Accordingly, I highly recommend to have exclusive recovery storage accounts per virtual machine to ease housekeeping.
By default, when you open the “All resources” list, the portal does not show the resources created/managed by Azure. Microsoft calls these resources “ancillary”. To see really all resources connected with the virtual machine, one need to checkmark the “Show hidden type” option.
If you want to see the hidden types included in a resource group, you need to first click on the “Clear filters / Show hidden” button after opening the resource group in the portal. This will then show the “Show hidden type” option.
These were the hidden things I found:
|AzureBackup_First-VM_arbitrage number||microsoft.compute/restorepointcollections||The restore point collection of my virtual machine|
|IaaSAntimalware (First-VM/IaaSAntimalware)||microsoft.compute/virtualmachines/extensions||The antimalware extension of my virtual machine; got lost when performing failover|
|NetworkWatcher_location||microsoft.network/networkwatchers||Network watcher for the recovery source location|
|NetworkWatcher_location||microsoft.network/networkwatchers||Network watcher for the recovery target location|
|shutdown-computevm-First-VM||microsoft.devtestlab/schedules||Schedule for automated shutdown of my virtual machine|
|SiteRecovery-Windows (First-VM/SiteRecovery-Windows)||microsoft.compute/virtualmachines/extensions||Extension for recovery of my virtual machine|
In total, five resource groups, twenty-five resources (six of them hidden), and ten blob containers were created by me or Azure to setup the virtual machine. And this is before following the security recommendations given by the Azure Advisor.
Comparing this with the minimum list of resources created based on Microsoft’s tutorial “Compile a checklist for creating an Azure Virtual Machine“, this is surprisingly much of resources.
The post “Minimum required Elements for Microsoft Azure VMs” presents the list of elements I identified as the minimum.
Notes and Observations when setting up a Virtual Machine in Microsoft Azure
Principles of Resource Groups
Azure Site Recovery
Tutorial “Compile a checklist for creating an Azure Virtual Machine” by Microsoft
Minimum required Elements for Microsoft Azure VMs