Exploring VM and Server Types from Azure’s Point of View

Windows, Linux, Bare Metal, VMs, AIX, Solaris, blah blah, this is easy right? We understand what different types of server there are and how to manage them right?

Well no, probably not, because we’re talking in the context of Azure and Azure Arc here specifically, and here things get more interesting.

Over the course of the last couple of years, a bunch of different Server type definitions have sprung up, which enable (or not) various pieces of Azure functionality depending on what the definition is.

By my count there are seven different definitions of various levels of interest for us to wade through here, so buckle up, because here we go!

#1 - Azure VMs

This is probably the simplest! Azure VMs run inside Azure datacenters (and technically Azure Stack Hub as well, but we’ll bypass that piece for now). An Azure VM is identified by the Azure VM Agent that runs inside every Azure VM. The Azure VM Agent package consists of two parts - the Azure Provisioning Agent and the Azure Guest Agent. The Provisioning Agent is required to boot an Azure VM, the Guest Agent is required to enable Azure Extensions which then enable various functionality like Azure Backup, Azure Security, and basically everything else you’re used to in Azure.

If you look at the properties of any Azure VM, you’ll see its agent properties. Hello little agent! This is what enables the Azure features and functionality it’s entitled to. Hurrah!

#2 Azure Arc-enabled Server

Our next server type is the Azure Arc-enabled Server. This is the definition given to any Windows or Linux server which has the Azure Arc agent installed on it, with the exception of some of the below. The Azure Arc agent projects any Windows or Linux server (physical or virtual, on-prem or non-Azure-cloud) into the Azure portal to enable a subset of Azure functionality. Similar to the Azure Machine Agent, the fact that this is an Azure Arc machine with the Arc Agent is what identifies what subset of Azure functionality the server is entitled to. Apply Azure Policy, deploy Azure Extensions, use Azure Update Management to manage the lifecycle of the server, a whole bunch of stuff - just not the gamut available for Azure VMs.

Some of the functionality enabled also has cost associated that Azure VMs don’t incur - for example, Azure Update Management costs $5 per instance for Azure Arc-enabled servers, while it’s free for Azure VMs.

#3 - Hyper-V VMs

To move forward with our final category, we need to address Hyper-V. A VM running on Hyper-V and not connected to Azure is considered a basic Hyper-V VM. It isn’t entitled to any Arc-enabled features or functionality, and operates isolated from the Public Cloud. If you then Arc-enable a Hyper-V VM, Azure considers it a standard Azure Arc-enabled server, no different to an Arc-enabled server running on VMware, AWS, bare metal, or anywhere else. All of this just to say, Hyper-V VMs are not considered special when connected to Azure.

#4 - Azure Stack HCI VMs

Here now we’ve arrived at the purpose of this blog - the reason for going through this exercise, because what we define here is going to inform and be called back to from a bunch of upcoming blogs, that I couldn’t write without first getting this out of the way.

Speaking of calling back, we now need to call back to this blog, which defined what Azure Stack HCI is in 2024. Specifically, it’s no longer a cloud-connected operating system, it’s a hybrid cloud solution which includes the Arc Resource Bridge, and a bunch of Azure Arc Extensions out of the box. The Arc Resource Bridge is the key to our story here, as it’s what handles the provisioning of VMs inside Azure Stack HCI 23H2 onwards.

What does this mean?

If I open up Failover Cluster Manager, connect it to my Azure Stack HCI cluster, and create a VM through that interface, what type of VM do I have? I have a Hyper-V VM.

If I then open up that VM, install the Arc Agent on it, and connect it to Azure, what kind of VM do I have? I have an Azure Arc-enabled VM.

So what’s an Azure Stack HCI VM then?

If I login to Azure, open up my Azure Stack HCI cluster and deploy a VM from there, the path it’s going to take is Azure Resource Manager talking to the Arc Resource Bridge, which will then provision the VM on the Hyper-V cluster, and hydrate it as an Azure Stack HCI VM. This involves a combination of installing the Arc Connected Agent on the VM, and some data/metadata stored inside the Arc Resource Bridge itself.

If we look at that VM in the Azure Portal, we’ll see that it’s subtly different from other Arc-enabled servers - it’s explicitly listed as an Azure Stack HCI VM.

The other feature this enables is the ability to manage it from the Azure Portal now. Note that in the screenshot below, it explicitly notes that only VMs created via the Azure Portal are shown here. What it really means is that only VMs created via the Arc Resource Bridge will be shown here.

So why is all of this important? Why does it feed into future blogs?

We’ve already established that how a server is identified in Azure defines what features, functionality, and cost-benefits that server is entitled to. If you want to manage your VM estate from Azure, if you want to use VM hotpatching, SMB over QUIC, Azure Extended Network, Storage Replica Compression and more, if you want to get Azure Update Management for free, manage your workloads via AzCLI or ARM, want to use Azure Automanage for your VMs, provision disks, resize your VM, change network config, and so on, and so on… All of this is gated behind your VMs being correctly identified as Azure Stack HCI VMs.

This is all well and good for new VMs - just deploy them via ARM, hurrah! Done.

But how then does migration work? How do I migrate my existing VMs from VMware, Hyper-V, or anywhere else into Azure Stack HCI and have those VMs correctly identify as Azure Stack HCI VMs.

Stay tuned! That’s the subject for another day - but at least we’re now teed up for it.

But wait, I said there are seven interesting server types - what about the other three? Arc-enabled VMware, Arc-enabled SCVMM, and Arc-enabled VMware vSphere for Azure VMware Solution are all things as well - but they’re also a subject for another day.