
close
close
Upcoming FREE Conference on Identity Management and Privileged Access Management
I find it important to understand the basic makeup of an Azure virtual machine. Understanding the basics not only helps you understand how to design and price virtual machines, but the knowledge also lends itself to troubleshooting machines that go wrong. In this post, I’ll explain at a high level how a virtual machine is made up in Azure.
The first thing to understand is that Azure is based on Windows Server 2012 Hyper-V, and no, I did not say Windows Server 2012 R2. Virtual machines in Azure are essentially the same as the ones you get with Hyper-V and aren’t that similar in concept as to what you get with vSphere.
If you understand Hyper-V, then some concepts will be familiar. For example, it’s required that any virtual machine running in Azure that will be a domain controller has a data disk to store the Active Directory database and SysVol; veteran Hyper-V administrators will be familiar with this advice from Microsoft.
If you’ve ever worked with a virtual machine with on-premises virtualization, then you will be familiar with the concept of virtual disks.
An Azure virtual machine is made up of metadata and virtual hard disks (Image Credit: Aidan Finn)
Have you ever gone browsing the storage of vSphere or Hyper-V? Hyper-V virtual machines have an XML file (pre-Windows Server 2016) that describes the configuration of a virtual machine. vSphere uses a VMX file to accomplish the same task.
These metadata files describe the configuration of the virtual machine. Memory, CPU, network connections, storage controllers and more are described. Those storage controllers describe what disks are connected to the virtual machine. For example, the OS disk is the boot device. When you start a virtual machine, it consumes resources from the host and connects to the defined disks.
There are two primary costs to a virtual machine in Azure:
Lots of virtualization administrators have deleted a virtual machine, while opting to keep the disks. They then create a new virtual machine and attach the old disks. This is an old technique to resolve an issue of metadata corruption.
We can do something similar in Azure too. Imagine that you create a virtual machine that was connected to “Virtual Network A.” You spend ages working on the machine and then realize that it should have been connected to “Virtual Network B.” You cannot change the virtual network connection of an Azure virtual machine. But what you can do is delete the Azure virtual machine, choosing to retain the virtual hard disks, and then create a new virtual machine from the existing OS disk and data disks, and select the correct virtual network.
This is a classic example of where understanding the difference between metadata and disks is important, and how Azure virtual machines aren’t all that different to what we’ve been working with on-premises for many years.
More in Microsoft Azure
Microsoft's Azure OpenAI Service Gets New ChatGPT Integration in Preview
Mar 9, 2023 | Rabia Noureen
Microsoft's New Azure Operator Nexus Solution Now Available in Public Preview
Mar 2, 2023 | Rabia Noureen
Microsoft Introduces Fully-Managed Azure Load Testing Service for Developers
Feb 2, 2023 | Rabia Noureen
Azure Native New Relic Service Provides Full Stack Observability To Boost Digital Transformation
Jan 25, 2023 | Rabia Noureen
Microsoft to Roll Out EU Data Boundary Plan for Cloud Services on January 1
Dec 15, 2022 | Rabia Noureen
Most popular on petri