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 |
Copy file name to clipboardExpand all lines: articles/synapse-analytics/spark/apache-spark-35-runtime.md
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,7 +29,10 @@ Azure Synapse Analytics supports multiple runtimes for Apache Spark. This docume
29
29
> For up-to-date information, a detailed list of changes, and specific release notes for Spark runtimes, check and subscribe [Spark Runtimes Releases and Updates](https://github.com/microsoft/synapse-spark-runtime/tree/main/Synapse/spark3.5).
30
30
## Libraries
31
31
32
-
To check the libraries included in Azure Synapse Runtime for Apache Spark 3.5 for Java/Scala, Python and R go to [Azure Synapse Runtime for Apache Spark 3.5 Releases Notes](https://github.com/microsoft/synapse-spark-runtime/tree/main/Synapse/spark3.5).
32
+
To check the libraries included in Azure Synapse Runtime for Apache Spark 3.5 for Java/Scala, Python and R go to [Azure Synapse Runtime for Apache Spark 3.5 Releases Notes](https://github.com/microsoft/synapse-spark-runtime/tree/main/Synapse/spark3.5).
33
+
34
+
> [!NOTE]
35
+
> EventHubConnector is deprecated in Synapse Spark 3.5 and will be removed in future. Customers are encouraged to use Kafa Spark Connector instead as Event Hubs is Kafka compatible already. You can find more information about using Kafa Spark Connector with Event Hubs here: [https://learn.microsoft.com/azure/event-hubs/event-hubs-kafka-spark-tutorial](https://learn.microsoft.com/azure/event-hubs/event-hubs-kafka-spark-tutorial)
33
36
34
37
## Related content
35
38
-[Migration between Apache Spark versions - support](./apache-spark-version-support.md#migration-between-apache-spark-versions---support)
* For VpnGw1 CSES to VMSS migration, we are seeing higher CPU utilization due to .NET core optimization. This is a known issue and we recommend to either wait for 10 minutes after prepare stage or upgrade to a higher gateway SKU during the migration process.
145
+
* Migration Limitation – Point-to-Site VPN Gateways using legacy DNS : Gateways that were created with the older cloudapp.net DNS do not yet have a supported migration path. A guided migration experience is planned, and the tentative timeline will be shared by the end of September 2025.
146
+
- Do *NOT* remove your existing Point-to-Site configuration to perform this migration
147
+
- On your existing gateway, if you do not have an existing point-to-site configuration, do not add this point-to-site configuration until this migration capability is released
148
+
* Follow these steps to check if your gateway falls into the legacy DNS category:
149
+
- In the Azure portal, navigate to you Virtual Network Gateway.
150
+
- Go to Settings -> Point-to-site configuration.
151
+
- Download VPN Client
152
+
- Then, extract the downloaded config zip to some local directory on your machine.
153
+
- Go to AzureVPN folder and open “azurevpnconfig.xml” file.
154
+
- Look for serverlist -> serverEntry -> fqdn. Check the suffix of the fqdn.
155
+
- If FQDN has suffix “cloudapp.net”, then it means that your gateway is on cloudapp.net based VPN gateway server.
0 commit comments