| title | Introduction |
|---|---|
| description | Learn the features and benefits of Azure VMware Solution to deploy and manage VMware-based workloads in Azure. |
| ms.topic | overview |
| ms.service | azure-vmware |
| ms.date | 12/19/2025 |
| ms.custom | engagement-fy23 |
Azure VMware Solution provides private clouds that contain VMware vSphere clusters built from dedicated bare-metal Azure infrastructure. Azure VMware Solution is available in Azure Commercial and Azure Government. The minimum initial deployment is three hosts, with the option to add more hosts, up to a maximum of 16 hosts per cluster. All provisioned private clouds have VMware vCenter Server, VMware vSAN, VMware vSphere, and VMware NSX. As a result, you can migrate workloads from your on-premises environments, deploy new virtual machines (VMs), and consume Azure services from your private clouds. For information about the SLA, see the Azure service-level agreements page.
Azure VMware Solution is a VMware validated solution with ongoing validation and testing of enhancements and upgrades. Microsoft manages and maintains the private cloud infrastructure and software, allowing you to focus on developing and running workloads in your private clouds to deliver business value.
The diagram shows the adjacency between private clouds and VNets in Azure, Azure services, and on-premises environments. Network access from private clouds to Azure services or VNets provides SLA-driven integration of Azure service endpoints. ExpressRoute Global Reach connects your on-premises environment to your Azure VMware Solution private cloud.
:::image type="content" source="media/introduction/adjacency-overview-drawing-final.png" alt-text="Diagram showing Azure VMware Solution private cloud adjacency to Azure services and on-premises environments." border="false" lightbox="media/introduction/adjacency-overview-drawing-final.png":::
Azure VMware Solution provides two different private cloud generations:
-
Azure VMware Solution Generation 1 provides VMware vSphere clusters built from dedicated bare-metal hosts deployed in Azure data center facilities. Microsoft-managed ExpressRoute circuits provide connectivity between VMware vSphere hosts and native Azure resources deployed in Virtual Networks.
-
Azure VMware Solution Generation 2 provides VMware vSphere clusters built from dedicated Azure bare-metal hosts. Azure VMware Solution Generation 2 features an updated network architecture whereby VMware vSphere hosts are directly attached to Azure Virtual Networks. This offering is only supported on the AV64 SKU.
[!INCLUDE host-sku-sizes]
You can deploy new or scale existing private clouds through the Azure portal or Azure CLI.
The AV64 is an Azure VMware Solution host SKU, which is available to expand the Azure VMware Solution private cloud built with the existing AV36, AV36P, or AV52 SKU. If you want to deploy AV64 directly, refer to Azure VMware Solution in an Azure Virtual Network. Use the Microsoft documentation to check for availability of the AV64 SKU in the region.
:::image type="content" source="media/introduction/av64-mixed-sku-topology.png" alt-text="Diagram showing Azure VMware Solution private cloud with AV64 SKU in mixed SKU configuration." border="false" lightbox="media/introduction/av64-mixed-sku-topology.png":::
See the following prerequisites for AV64 cluster deployment.
-
An Azure VMware solution private cloud is created using AV36, AV36P, AV48, or AV52 in AV64 supported region/AZ.
-
You need one /23 or three (contiguous or noncontiguous) /25 address blocks for AV64 cluster management.
Customer with existing Azure VMware Solution private cloud: When a customer has a deployed Azure VMware Solution private cloud, they can scale the private cloud by adding a separate AV64 vCenter node cluster to that private cloud. In this scenario, customers should use the following steps:
- Get an AV64 quota approval from Microsoft with the minimum of three nodes. Add other details on the Azure VMware Solution private cloud that you plan to extend using AV64.
- Use an existing Azure VMware Solution add-cluster workflow with AV64 hosts to expand.
Customer plans to create a new Azure VMware Solution private cloud: When a customer wants a new Azure VMware Solution private cloud that can use AV64 SKU but only for expansion. In this case, the customer meets the prerequisite of having an Azure VMware Solution private cloud built with AV36, AV36P, or AV52 SKU. The customer needs to buy a minimum of three nodes of AV36, AV36P, or AV52 SKU before expanding using AV64. For this scenario, use the following steps:
- Get AV36, AV36P, or AV52, and AV64 quota approval from Microsoft with a minimum of three nodes each.
- Create an Azure VMware Solution private cloud using AV36, AV36P, or AV52 SKU.
- Use an existing Azure VMware Solution add-cluster workflow with AV64 hosts to expand.
Azure VMware Solution stretched clusters private cloud: The AV64 SKU isn't supported with Azure VMware Solution stretched clusters private cloud. This means that an AV64-based expansion isn't possible for an Azure VMware Solution stretched clusters private cloud.
Note
All traffic from an AV64 host towards a customer network will utilize the IP address of the VMKernel Network Interface 1.
Adding AV64 nodes to an Azure VMware Solution private cloud creates a heterogeneous environment, which results in Enhanced vMotion Compatibility (EVC) issues between AV64 clusters and base SKU clusters using AV36, AV36P, or AV52 SKUs. AV64 clusters use the Icelake EVC mode due to their Intel Icelake CPUs, whereas AV36, AV36P, and AV52 clusters, built on older Intel CPUs, do not have explicit EVC mode enabled. Details on CPU generations for each SKU are provided above.
The heterogeneity of EVC modes across clusters presents challenges for live vMotion operations, as defined by Broadcom, based on the specific scenario and direction of migration. The following section provides a summary of the user experience when performing live vMotion between AV64 and the base clusters.
-
vMotion to AV64 cluster from Base SKU cluster – this works fine as virtual machine is vMotioned from lower EVC mode cluster to higher EVC mode cluster.
-
vMotion to base SKU cluster from AV64 cluster – two scenarios
-
If virtual machine was previously moved from base cluster and not power cycled, then the live vMotion succeeds.
-
If virtual machine was created on AV64 cluster or power cycled, even though it was previously vMotioned from the base SKU cluster, live vMotion will fail with EVC compatibility error.
-
Customers can avoid live vMotion problems between base SKU and AV64 clusters by setting the VM-level EVC mode to match a lower base cluster EVC, or by powering off the virtual machine and doing a cold vMotion.
The traditional Azure VMware Solution host clusters don't have explicit vSAN FD configuration. The reasoning is the host allocation logic ensures, within clusters, that no two hosts reside in the same physical fault domain within an Azure region. This feature inherently brings resilience and high availability for storage, which the vSAN FD configuration is supposed to bring. More information on vSAN FD can be found in the VMware documentation.
The Azure VMware Solution AV64 host clusters have an explicit vSAN fault domain (FD) configuration. Azure VMware Solution control plane configures seven vSAN fault domains (FDs) for AV64 clusters. Hosts are balanced evenly across the seven FDs as users scale up the hosts in a cluster from three nodes to 16 nodes. Some Azure regions still support a maximum of five FDs as part of the initial release of the AV64 SKU. Refer to the Azure region availability zone to host type mapping table for more information.
The Azure VMware Solution minimum vSphere node cluster size supported is three. The vSAN data redundancy is handled by ensuring the minimum cluster size of three hosts are in different vSAN FDs. In a vSAN cluster with three hosts, each in a different FD, should an FD fail (for example, the top of rack switch fails), the vSAN data would be protected. Operations such as object creation (new VM, VMDK, and others) would fail. The same is true of any maintenance activities where an ESXi host is placed into maintenance mode and/or rebooted. To avoid scenarios such as these, the recommendation is to deploy vSAN clusters with a minimum of four ESXi hosts.
Because of the AV64 cluster vSAN fault domain (FD) configuration and need for hosts balanced across all FDs, the host removal from AV64 cluster differs from traditional Azure VMware Solution host clusters with other SKUs.
Currently, a user can select one or more hosts to be removed from the cluster using portal or API. One condition is that a cluster should have a minimum of three hosts. However, an AV64 cluster behaves differently in certain scenarios when AV64 uses vSAN FDs. Any host removal request is checked against potential vSAN FD imbalance. If a host removal request creates an imbalance, the request is rejected with the http 409-Conflict response. The http 409-Conflict response status code indicates a request conflict with the current state of the target resource (hosts).
The following three scenarios show examples of instances that normally error out and demonstrate different methods that can be used to remove hosts without creating a vSAN fault domain (FD) imbalance.
-
Removing a host creates a vSAN FD imbalance with a difference of hosts between most and least populated FD to be more than one. In the following example users, need to remove one of the hosts from FD 1 before removing hosts from other FDs.
:::image type="content" source="media/introduction/remove-host-scenario-1.png" alt-text="Diagram showing how users need to remove one of the hosts from FD 1 before removing hosts from other FDs." border="false" lightbox="media/introduction/remove-host-scenario-1.png":::
-
Multiple host removal requests are made at the same time and certain host removals create an imbalance. In this scenario, the Azure VMware Solution control plane removes only hosts, which don't create imbalance. In the following example users can't take both of the hosts from the same FDs unless they're reducing the cluster size to four or lower.
:::image type="content" source="media/introduction/remove-host-scenario-2.png" alt-text="Diagram showing how users can't take both of the hosts from the same FDs unless they're reducing the cluster size to four or lower." border="false" lightbox="media/introduction/remove-host-scenario-2.png":::
-
A selected host removal causes less than three active vSAN FDs. This scenario isn't expected to occur given that all AV64 regions have five or seven FDs. While adding hosts, the Azure VMware Solution control plane takes care of adding hosts from all seven FDs evenly. In the following example, users can remove one of the hosts from FD 1, but not from FD 2 or 3.
:::image type="content" source="media/introduction/remove-host-scenario-3.png" alt-text="Diagram showing how users can remove one of the hosts from FD 1, but not from FD 2 or 3." border="false" lightbox="media/introduction/remove-host-scenario-3.png":::
How to identify the host that can be removed without causing a vSAN FD imbalance: A user can go to the vSphere Client interface to get the current state of vSAN FDs and hosts associated with each of them. This helps to identify hosts (based on the previous examples) that can be removed without affecting the vSAN FD balance and avoid any errors in the removal operation.
This table provides the list of RAID configuration supported and host requirements in AV64 clusters. The RAID-6 FTT2 and RAID-1 FTT3 policies are supported with the AV64 SKU in some regions. In Azure regions that are currently constrained to five FDs, Microsoft allows customers to use the RAID-5 FTT1 vSAN storage policy for AV64 clusters with six or more nodes to meet the service level agreement (SLA). Refer to the Azure region availability zone to host type mapping table for more information.
| RAID configuration | Failures to tolerate (FTT) | Minimum hosts required |
|---|---|---|
| RAID-1 (Mirroring) Default setting. | 1 | 3 |
| RAID-5 (Erasure Coding) | 1 | 4 |
| RAID-1 (Mirroring) | 2 | 5 |
| RAID-6 (Erasure Coding) | 2 | 6 |
| RAID-1 (Mirroring) | 3 | 7 |
Azure VMware Solution supports the expansion of datastore capacity beyond what is included with vSAN using Azure storage services, enabling you to expand datastore capacity without scaling the clusters. For more information, see Datastore capacity expansion options.
[!INCLUDE avs-networking-description]
For more information, see Networking architecture.
Azure VMware Solution private clouds use vSphere role-based access control for enhanced security. You can integrate vSphere SSO LDAP capabilities with Microsoft Entra ID. For more information, see the Access and identity architecture page.
vSAN data-at-rest encryption, by default, is enabled and is used to provide vSAN datastore security. For more information, see Storage architecture.
Azure VMware Solution doesn't store customer data.
[!INCLUDE vmware-software-versions]
Regular upgrades of the Azure VMware Solution private cloud and VMware software ensure the latest security, stability, and feature sets are running in your private clouds. For more information, see Host maintenance and lifecycle management.
Once you deployed Azure VMware Solution into your subscription, Azure Monitor logs are generated automatically.
In your private cloud, you can:
- Collect logs on each of your VMs.
- Download and install the MMA agent on Linux and Windows VMs.
- Enable the Azure diagnostics extension.
- Create and run new queries.
- Run the same queries you usually run on your VMs.
Monitoring patterns inside the Azure VMware Solution are similar to Azure VMs within the IaaS platform. For more information and how-tos, see Monitoring Azure VMs with Azure Monitor.
[!INCLUDE customer-communications]
Azure VMware Solution implements a shared responsibility model that defines distinct roles and responsibilities of the two parties involved in the offering: customer and Microsoft. The shared role responsibilities are illustrated in more detail in the following two tables.
The shared responsibility matrix table outlines the main tasks that customers and Microsoft each handle in deploying and managing both the private cloud and customer application workloads.
:::image type="content" source="media/introduction/azure-introduction-shared-responsibility-matrix.png" alt-text="Diagram of the high-level shared responsibility matrix for Azure VMware Solution." border="false" lightbox="media/introduction/azure-introduction-shared-responsibility-matrix.png":::
The following table provides a detailed list of roles and responsibilities between the customer and Microsoft, which encompasses the most frequent tasks and definitions. For further questions, contact Microsoft.
| Role | Task/details |
|---|---|
| Microsoft - Azure VMware Solution | Physical infrastructure
(optional) VMware HCX deploys with fully configured compute profile on cloud side as add-on (optional) VMware SRM deploys, upgrade, and scale up/down Support - Private cloud platforms and VMware HCX |
| Customer | Request Azure VMware Solution host quote with Microsoft Plan and create a request for private clouds on Azure portal with:
Add or delete hosts requests to cluster from Portal Deploy/lifecycle management of partner (third party) solutions |
| Partner ecosystem | Support for their product/solution. For reference, the following are some of the supported Azure VMware Solution partner solution/product:
|
The next step is to learn key private cloud architecture concepts.