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/api-center/register-discover-mcp-server.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ ms.custom:
18
18
This article describes how to use Azure API Center to maintain an inventory (or *registry*) of remote model context protocol (MCP) servers and help stakeholders discover them through the API Center portal. MCP servers expose backend APIs or data sources in a standard way to AI agents and models that consume them.
19
19
20
20
> [!NOTE]
21
-
> New! MCP servers registered in your API Center can now be integrated with Azure AI Foundry's tool catalogs, enabling you to govern MCP tools and make them available to AI agents. Learn more in [Tool catalog for agents in Azure AI Foundry](/azure/ai-foundry/agents/concepts/tool-catalog) and [Private tool catalogs for Azure AI Foundry agents](/azure/ai-foundry/agents/how-to/private-tool-catalog).
21
+
> New! MCP servers registered in your API Center can now be integrated with Microsoft Foundry's tool catalogs, enabling you to govern MCP tools and make them available to AI agents. Learn more in [Tool catalog for agents in Foundry](/azure/ai-foundry/agents/concepts/tool-catalog) and [Private tool catalogs for Foundry agents](/azure/ai-foundry/agents/how-to/private-tool-catalog).
Copy file name to clipboardExpand all lines: articles/automation/shared-resources/modules.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -61,7 +61,7 @@ The following table lists the modules that Azure Automation imports by default w
61
61
62
62
The default modules are also known as global modules. In the Azure portal, the **Global module** property will be **true** when viewing a module that was imported when the account was created.
63
63
64
-
64
+
65
65
66
66
> [!NOTE]
67
67
> We don't recommend altering modules and runbooks in Automation accounts used for deployment of the [Start/Stop VMs during off-hours](../../azure-functions/start-stop-vms/overview.md)
Copy file name to clipboardExpand all lines: articles/azure-vmware/attach-azure-netapp-files-to-azure-vmware-solution-hosts.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -125,7 +125,7 @@ There are some important best practices to follow for optimal performance of NFS
125
125
- Based on your performance requirements, select the correct service level needed for the Azure NetApp Files capacity pool. See [Service levels for Azure NetApp Files](../azure-netapp-files/azure-netapp-files-service-levels.md) to understand the throughput allowed per provisioned TiB for each service level.
126
126
127
127
>[!IMPORTANT]
128
-
> If you've changed the Azure NetApp Files volumes performance tier or the volume size after creating the volume and datastore, see [Service level change for Azure NetApp files datastore](#service-level-change-for-azure-netapp-files-datastore) to ensure that volume/datastore metadata is in sync to avoid unexpected behavior in the portal or the API due to metadata mismatch. To do any kind of change to the volume you can use Azure Portal or any other supported solution (CLI\Powershell\API).
128
+
> If you've changed the Azure NetApp Files volumes performance tier or the volume size after creating the volume and datastore, see [Service level change for Azure NetApp files datastore](#service-level-change-for-azure-netapp-files-datastore) to ensure that volume/datastore metadata is in sync to avoid unexpected behavior in the portal or the API due to metadata mismatch. To do any kind of change to the volume you can use Azure portal or any other supported solution (CLI\PowerShell\API).
129
129
130
130
- Create one or more volumes based on the required throughput and capacity. See [Performance considerations](../azure-netapp-files/azure-netapp-files-performance-considerations.md) for Azure NetApp Files to understand how volume size, service level, and capacity pool QoS type determines volume throughput. For assistance calculating workload capacity and performance requirements, contact your Azure VMware Solution or Azure NetApp Files field expert. The default maximum number of Azure NetApp Files datastores is 64.
131
131
@@ -228,7 +228,7 @@ az vmware datastore netapp-volume create \
228
228
229
229
You can use the instructions provided to delete an Azure NetApp Files-based datastore using either Azure portal or Azure CLI. There's no maintenance window required for this operation. The delete action only removes the Azure NetApp Files volume as a datastore and it doesn't delete the data or the Azure NetApp Files volume.
230
230
231
-
**Delete an Azure NetApp Files datastore using the Azure Portal**
231
+
**Delete an Azure NetApp Files datastore using the Azure portal**
Copy file name to clipboardExpand all lines: articles/azure-vmware/native-network-design-consideration.md
+21-26Lines changed: 21 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,32 +20,27 @@ This article outlines key design considerations for Azure VMware Solution Genera
20
20
21
21
The following functionality is limited during this time. These limitations will be lifted in the future:
22
22
23
-
1. You cannot delete your **Resource Group**, which contains your private cloud. You must delete the private cloud first before deleting the resource group.
24
-
2. You can only deploy **1 private cloud per Azure virtual network**.
25
-
1. You can only create **1 private cloud per Resource Group**. Multiple private clouds in a single Resource Group are not supported.
26
-
27
-
4. Your private cloud and virtual network for your private cloud must be in the ***same*** Resource Group.
28
-
5. You cannot ***move*** your private cloud from one Resource Group to another after the private cloud is created.
29
-
6. You cannot ***move*** your private cloud from one tenant to another after the private cloud is created.
30
-
1. If you require **ExpressRoute FastPath** or **Global Virtual Network Peering** for your AVS Private Cloud**,** create a Support Case through the Azure Portal.
31
-
32
-
1.**Service Endpoints** direct connectivity from Azure VMware Solution workloads isn't supported.
33
-
34
-
1.**Private Endpoints when globally peered** across regions connected to Azure VMware Solution isn't supported.
35
-
36
-
9.**vCloud Director** using Private Endpoints is supported. However, vCloud Director using Public Endpoints isn't supported.
37
-
1.**vSAN Stretched Clusters** isn't supported.
38
-
39
-
11.**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).
40
-
1. During **unplanned maintenance** – like a host hardware failure – on any of the first four hosts in your SDDC, you may experience a temporary North-South network connectivity disruption for some workloads, lasting up to 30 seconds. North-South connectivity refers to traffic between your AVS VMware workloads and external endpoints beyond the NSX-T Tier-0 (T0) Edge, such as Azure services or on-premises environments. This limitation has been removed in specific Azure regions. Check with with Azure Support to see if your region is affected by this limitation.
41
-
13.**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.
42
-
14.**Cross-resource group and cross-subscription 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 or subscription than the Azure VMware Solution virtual network, network programming (such as NSX segment propagation) may fail. To avoid issues, customers must ensure that the Azure VMware Solution virtual network isn't linked to resources in a different resource group or subscription and detach such resources (for example, DDoS Protection Plans) from the virtual network before proceeding.
43
-
- To maintain your cross-resource group reference, create a role assignment from your cross-resource group or subscription and give the “AzS VIS Prod App” the "AVS on Fleet VIS Role". The role assignment allows you to use reference and have your reference correctly applied for your Azure VMware Solution private cloud.
44
-
15. Gen 2 private cloud **deployments may fail if Azure policies that enforce strict rules for Network Security Groups or route tables (for example, specific naming conventions)**. These policy constraints can block required Azure VMware Solution Network Security Group and route table creation during deployment. You must remove these policies from the Azure VMware Solution virtual network before deploying your private cloud. Once your private cloud is deployed, these policies can be added back to your Azure VMware Solution private cloud.
45
-
16. If you are using **Private DNS** for your Azure VMware Solution Gen 2 private cloud, using **Custom DNS** on the virtual network where an Azure VMware Solution Gen 2 private cloud is deployed is unsupported. Custom DNS breaks lifecycle operations such as scaling, upgrades, and patching.
46
-
17. If you are **deleting** your private cloud and some Azure VMware Solution created resources are not removed, you can retry the deletion of the Azure VMware Solution private cloud using the Azure CLI.
47
-
18. Azure VMware Solution Gen 2 uses an HTTP Proxy to distinguish between customer and management network traffic. Certain VMware cloud service endpoints **may not follow the same network path or proxy rules as general vCenter-managed traffic**. Examples include: "scapi.vmware" and "apigw.vmware". The VAMI proxy governs the vCenter Server Appliance’s (VCSA) general outbound internet access, but not all service endpoint interactions flow through this proxy. Some interactions originate directly from the user’s browser or from integration components, which instead follow the workstation’s proxy settings or initiate connections independently. As a result, traffic to VMware cloud service endpoints may bypass the VCSA proxy entirely.
48
-
1. HCX RAV and Bulk migrations on Gen 2 can experience significantly slower performance due to stalls during Base Sync and Online Sync phases. Customers should plan for longer migration windows and schedule waves accordingly for now. For suitable workloads, vMotion offers a faster, low‑overhead option when host and network conditions allow.
23
+
- You cannot delete your **Resource Group**, which contains your private cloud. You must delete the private cloud first before deleting the resource group.
24
+
- You can only deploy **1 private cloud per Azure virtual network**.
25
+
- You can only create **1 private cloud per Resource Group**. Multiple private clouds in a single Resource Group are not supported.
26
+
- Your private cloud and virtual network for your private cloud must be in the ***same*** Resource Group.
27
+
- You cannot ***move*** your private cloud from one Resource Group to another after the private cloud is created.
28
+
- You cannot ***move*** your private cloud from one tenant to another after the private cloud is created.
29
+
- If you require **ExpressRoute FastPath** or **Global Virtual Network Peering** for your AVS Private Cloud, create a Support Case through the Azure portal.
30
+
-**Service Endpoints** direct connectivity from Azure VMware Solution workloads isn't supported.
31
+
-**Private Endpoints when globally peered** across regions connected to Azure VMware Solution isn't supported.
32
+
-**vCloud Director** using Private Endpoints is supported. However, vCloud Director using Public Endpoints isn't supported.
33
+
-**vSAN Stretched Clusters** isn't supported.
34
+
-**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).
35
+
- During **unplanned maintenance** – like a host hardware failure – on any of the first four hosts in your SDDC, you may experience a temporary North-South network connectivity disruption for some workloads, lasting up to 30 seconds. North-South connectivity refers to traffic between your AVS VMware workloads and external endpoints beyond the NSX-T Tier-0 (T0) Edge, such as Azure services or on-premises environments. This limitation has been removed in specific Azure regions. Check with with Azure Support to see if your region is affected by this limitation.
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.
37
+
-**Cross-resource group and cross-subscription 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 or subscription than the Azure VMware Solution virtual network, network programming (such as NSX segment propagation) may fail. To avoid issues, customers must ensure that the Azure VMware Solution virtual network isn't linked to resources in a different resource group or subscription and detach such resources (for example, DDoS Protection Plans) from the virtual network before proceeding.
38
+
- To maintain your cross-resource group reference, create a role assignment from your cross-resource group or subscription and give the “AzS VIS Prod App” the "AVS on Fleet VIS Role". The role assignment allows you to use reference and have your reference correctly applied for your Azure VMware Solution private cloud.
39
+
- Gen 2 private cloud **deployments may fail if Azure policies enforce strict rules for Network Security Groups or route tables (for example, specific naming conventions)**. These policy constraints can block required Azure VMware Solution Network Security Group and route table creation during deployment. You must remove these policies from the Azure VMware Solution virtual network before deploying your private cloud. Once your private cloud is deployed, these policies can be added back to your Azure VMware Solution private cloud.
40
+
- If you are using **Private DNS** for your Azure VMware Solution Gen 2 private cloud, using **Custom DNS** on the virtual network where an Azure VMware Solution Gen 2 private cloud is deployed is unsupported. Custom DNS breaks lifecycle operations such as scaling, upgrades, and patching.
41
+
- If you are **deleting** your private cloud and some Azure VMware Solution created resources are not removed, you can retry the deletion of the Azure VMware Solution private cloud using the Azure CLI.
42
+
- Azure VMware Solution Gen 2 uses an HTTP Proxy to distinguish between customer and management network traffic. Certain VMware cloud service endpoints **may not follow the same network path or proxy rules as general vCenter-managed traffic**. Examples include: "scapi.vmware" and "apigw.vmware". The VAMI proxy governs the vCenter Server Appliance’s (VCSA) general outbound internet access, but not all service endpoint interactions flow through this proxy. Some interactions originate directly from the user’s browser or from integration components, which instead follow the workstation’s proxy settings or initiate connections independently. As a result, traffic to VMware cloud service endpoints may bypass the VCSA proxy entirely.
43
+
- HCX RAV and Bulk migrations on Gen 2 can experience significantly slower performance due to stalls during Base Sync and Online Sync phases. Customers should plan for longer migration windows and schedule waves accordingly for now. For suitable workloads, vMotion offers a faster, low‑overhead option when host and network conditions allow.
0 commit comments