You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-vmware/native-network-design-consideration.md
+30-25Lines changed: 30 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,12 +10,12 @@ ms.custom:
10
10
# Customer intent: As a cloud administrator, I want to understand the design considerations for Azure VMware Solution Generation 2 private clouds so that I can effectively plan and implement my private cloud deployment while ensuring compliance with current limitations and requirements.
This article outlines key design considerations for Azure VMware Solution Generation 2 (Gen 2) private clouds. It explains the capabilities this generation brings to VMware-based private cloud environments, enabling access for your applications from both on-premises infrastructure and Azure-based resources. There are several considerations to review before you set up your Azure VMware Solution Gen 2 private cloud. This article provides solutions for use cases that you might encounter when you're using the private cloud type.
16
16
17
17
> [!Note]
18
-
> This is currently a Public Preview offering. For more information, see our [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/Preview-supplemental-terms/).
18
+
> Generation 2 is available in specific Azure public regions. SLAs are region specific. Contact your Microsoft account team or Microsoft Support to confirm coverage.
19
19
20
20
## Limitations during Public Preview
21
21
@@ -24,21 +24,26 @@ The following functionality is limited during this time. These limitations will
24
24
- You cannot delete your Resource Group, which contains your private cloud.
25
25
- You can only deploy **1 private cloud per Azure Virtual Network**.
26
26
- You can only create **1 private cloud per Resource Group**. Multiple private clouds in a single Resource Group are not supported.
27
-
- Your private cloud and Virtual Network for your private cloud must be in the *same* Resource Group.
28
-
- You cannot move your private cloud from one Resource Group to another after the private cloud is created.
29
-
- Virtual Network Service Endpoints direct connectivity from Azure VMware Solution workloads is not supported.
30
-
-**vCloud Director** using Private Endpoints is supported. However, vCloud Director using Public Endpoints is not supported.
31
-
-**vSAN Stretched Clusters**is not supported.
27
+
- Your private cloud and Virtual Network for your private cloud must be in the ***same*** Resource Group.
28
+
- You cannot ***move*** your private cloud from one Resource Group to another after the private cloud is created.
29
+
-**Virtual Network Service Endpoints** direct connectivity from Azure VMware Solution workloads aren't supported.
30
+
-Connectivity from **Azure VMware Solution (AVS) workloads to Azure virtual machines or to other AVS workloads** over Network File System (NFS) for Azure NetApp Files isn't supported.- **vCloud Director** using Private Endpoints is supported. However, vCloud Director using Public Endpoints isn't supported.
31
+
-**vSAN Stretched Clusters**isn't supported.
32
32
- Public IP down to the VMware NSX Microsoft Edge for configuring internet will not be supported. You can find what internet options are supported in [Internet connectivity options](native-internet-connectivity-design-considerations.md)
33
-
- Support for **AzCLI**, **PowerShell**, and **.NET SDK** are not available during Public Preview.
34
-
-**Run commands** interacting with customer segments aren't supported, including Zerto, JetStream, and other 3rd-party integrations.
35
33
36
-
-**Network Security Groups** associated with the private cloud host virtual network must be created in the same resource group as the private cloud and its virtual network.
34
+
-**Network Security Groups** associated with the private cloud host virtual network must be created in the ***same*** resource group as the private cloud and its virtual network.
37
35
36
+
-**Cross-resource group references** from customer virtual networks to the Azure VMware Solution virtual network are not supported by default. This includes resource types such as: User-defined routes (UDRs), DDoS Protection Plans and other linked networking resources. If a customer virtual network is associated with one of these references that resides in a different resource group than the Azure VMware Solution virtual network, network programming (such as NSX segment propagation) may fail.
37
+
38
+
- To avoid issues, customers must ensure that:
39
+
40
+
- The customer virtual network isn't linked to resources in a different resource group and detach such resources (for example, DDoS Protection Plans) from the virtual network before proceeding
41
+
42
+
- Create a role assignment from your cross-resource group to give the “AzS VIS Prod App” service principle "network contributor" access. The role assignment allows you to use reference and have your reference correctly applied for your Azure VMware Solution private cloud.
43
+
38
44
## Unsupported integrations during Public Preview
39
45
40
-
The following 1st-party and 3rd-party integrations won't be available during Public Preview:
41
-
-**Azure Elastic SAN**
46
+
The following 1st-party and 3rd-party integrations aren't be available:
42
47
-**Zerto DR**
43
48
-**JetStream DR**
44
49
@@ -49,7 +54,7 @@ Azure VMware Solution Gen 2 private clouds provide a VMware private cloud enviro
49
54
The private cloud connects to your Azure virtual network using standard Azure networking. Azure VMware Solution Gen 2 private clouds require a minimum /22 CIDR network address block for subnets. This network complements your on-premises networks, so the address block shouldn't overlap with address blocks used in other virtual networks in your subscription and on-premises networks. Management, vMotion, and Replication networks are provisioned automatically within this address block as subnets inside your Virtual Network.
50
55
51
56
> [!Note]
52
-
> Permitted ranges for your address block are the RFC 1918 private address spaces (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), except for 172.17.0.0/16. Replication network is not applicable to AV64 nodes and is planned for general deprecation at a future date.
57
+
> Permitted ranges for your address block are the RFC 1918 private address spaces (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), except for 172.17.0.0/16. Replication network isn't applicable to AV64 nodes and is planned for general deprecation at a future date.
53
58
54
59
Avoid using the following IP schema reserved for VMware NSX usage:
55
60
@@ -60,19 +65,19 @@ Avoid using the following IP schema reserved for VMware NSX usage:
60
65
61
66
Example /22 CIDR network address block **10.31.0.0/22** is divided into the following subnets:
|avs-mgmt| /27 | The management appliances (vCenter Server and NSX manager) are behind the "avs-mgmt” subnet, programmed as secondary IP ranges on this subnet. | 10.31.0.64/27 |
68
-
|avs-vnet-sync| /27 | Used by Azure VMware Solution Gen 2 to program routes created in VMware NSX into the virtual network. | 10.31.0.96/27 |
69
-
|avs-services | /27 | Used for Azure VMware Solution Gen 2 provider services. Also used to configure private DNS resolution for your private cloud. | 10.31.0.160/27 |
70
-
|avs-nsx-gw-1, avs-nsx-gw-2| /28 |Subnets off each of the T0 Gateways per edge. These subnets are used to program VMware NSX network segments as secondary IPs addresses. | 10.31.0.224/28, 10.31.0.240/28 |
71
-
|esx-mgmt-vmk1 | /24 | vmk1 is the management interface used by customers to access the host. IPs from the vmk1 interface come from these subnets. All of the vmk1 traffic for all hosts comes from this subnet range. | 10.31.1.0/24 |
|avs-mgmt| /27 | The management appliances (vCenter Server and NSX manager) are behind the "avs-mgmt” subnet, programmed as secondary IP ranges on this subnet. | 10.31.0.64/27 |
73
+
|avs-vnet-sync| /27 | Used by Azure VMware Solution Gen 2 to program routes created in VMware NSX into the virtual network. | 10.31.0.96/27 |
74
+
|avs-services | /27 | Used for Azure VMware Solution Gen 2 provider services. Also used to configure private DNS resolution for your private cloud. | 10.31.0.160/27 |
75
+
|avs-nsx-gw-1, avs-nsx-gw-2| /28 |Subnets off each of the T0 Gateways per edge. These subnets are used to program VMware NSX network segments as secondary IPs addresses. | 10.31.0.224/28, 10.31.0.240/28 |
76
+
|esx-mgmt-vmk1 | /24 | vmk1 is the management interface used by customers to access the host. IPs from the vmk1 interface come from these subnets. All of the vmk1 traffic for all hosts comes from this subnet range. | 10.31.1.0/24 |
0 commit comments