This is an Azure Arc Server (Server)

This is an Azure Arc Server (VMware)

This is an Azure Arc Server (HCI)

Introduction

Yes! Yes, Same Same… but different. Okay, so what? Not all Azure Arc Server VM objects are created equal. If we look a little closer at the Azure Resource Types we can see there are three different types listed here;

(Server) "type": "Microsoft.HybridCompute/machines"
(VMWare) "type": "microsoft.connectedvmwarevsphere/virtualmachines"
(HCI) "type": "microsoft.azurestackhci/virtualmachines"

Each of these types connecting via different methods to your Azure subscriptions, and along with this comes different functionality.

Server Blades

Let’s take a cursory look at (Server) using the standard connected Azure Connected Machine Agent. Lots of information, server, patch level, settings, operations, monitoring, big buttons to click great, appears feature rich and has the feel of Azure…. what’s your point?

Take note of the menu options on the left. You can also click on an image to enlarge it.

Okay, how about (VMWare)? It seems to be missing a few options and capability compared to the Server.

Well, what about (HCI)? Huh … It seems like its missing even more options.

VM Extensions

Unfortunately, this isn’t where the differences end. Taking a closer look at the Extensions available for each resource type. In particular, let’s say you want to start taking advantage of the new functionality around Arc-Enabled SQL Servers. Now the Arc SQL Extension is meant to Auto install… but only if you are using the (Server) type that is "type": "Microsoft.HybridCompute/machines"

For the other two types, that Arc SQL Server extension is missing.

HCI and VMWare

It is touted that it is easy to install Azure Arc for for your entire vSphere farm, and they are not wrong, you can import up to a maximum of 9500 VMs if you like with very little effort… up front. But you are not being offered all the benefits of an Azure Arc Server. You cant have the Arc SQL extension to monitor, operate and control your SQL Servers anywhere.

Digging into an HCI Cluster, you can Arc-enable the host nodes. These actually appear as first-class citizens of Azure as Azure Arc Servers.

Here is where you would start the setup for the HCI Resource Bridge Setup, and through this is where you connect servers the HCI clusters guests.

but while the hosts have the full feature set of an Arc Server the HCI cluster guest VMs don’t.

VMware and HCI types are seriously lagging behind Arc Server and missing features and are essentially second-class citizens of Azure compared to the original HybridCompute resource type. You can See Updates, Azure Monitor, and SQL Extensions are all only available for Azure Arc (Server).

Resource Explorer

Through the Resource Explorer in the Azure Portal we can see the different types and more specifically the different ways they have been enabled. (Server)

We can see the (VMWare) which has a number of operations at the cluster level

and (HCI) which also has more operations at the cluster level than at the VM level.

Conclusion

Of course, you can’t install multiple types on the same server. I believe Azure Arc (Server) is the only way to go. Seeing the lack of parity in functionality between these types, it’s worth creating a method to deploy Azure Connected Agent directly on the machine yourself and at scale rather than leveraging time savings tools with the Resource Bridge that allow easy onboarding of vSphere and HCI cluster guests which leverage the Arc Resource Bridge.

That’s not to say the Resource Bridge isn’t useful for K8s or Arc Data Services. However, you should be aware of the lack of feature parity for HCI or VMWare installations of Arc Server Resource Type and make an informed decision about which Resource Type of Azure Arc Server you need or want in your environment.