Merge pull request #113469 from georgewallace/release-preview-vmware

PRMerger15 · web-flow · commit 2869359a265d · 2020-04-30T20:35:57.000-07:00
Release preview vmware
diff --git a/articles/azure-vmware/concepts-identity.md b/articles/azure-vmware/concepts-identity.md
@@ -42,11 +42,9 @@ The CloudAdmin and CloudGlobalAdmin privileges are shown in the table below.
 |  Virtual Machine         |  A CloudAdmin user has all VirtualMachine privileges.  |  --  |  --  |
 |  vService                |  A CloudAdmin user has all vService privileges.  |  --  |  --  |
 
-Request elevated vCenter privileges with an SR in the Azure portal.
-
 ## NSX-T Manager access and identity
 
-You access NSX-T Manager using the "administrator" account. That account has full privileges and enables you to create and manage T1 routers, logical switches, and all services. The full privileges in NSX-T also provide you with access to the NSX-T T0 router. A change to the T0 router could result in degraded network performance or a loss of access to a private cloud. To meet support requirements, it's required that you open an SR in the Azure portal to request any changes to your NSX-T T0 router.
+You access NSX-T Manager using the "administrator" account. That account has full privileges and enables you to create and manage T1 routers, logical switches, and all services. The full privileges in NSX-T also provide you with access to the NSX-T T0 router. A change to the T0 router could result in degraded network performance or a loss of access to a private cloud. To meet support requirements, it's required that you open an support request in the Azure portal to request any changes to your NSX-T T0 router.
   
 ## Next steps
 
diff --git a/articles/azure-vmware/concepts-networking.md b/articles/azure-vmware/concepts-networking.md
@@ -50,14 +50,25 @@ To establish full interconnectivity to a private cloud, you use the Azure portal
 
 An on-premises to Azure virtual network ExpressRoute circuit is required to connect from on-premises environments to your private cloud in Azure. This ExpressRoute circuit is in your subscription and isn't part of a private cloud deployment. The on-premises ExpressRoute circuit is beyond the scope of this document. If you require on-premises connectivity to your private cloud, you can use one of your existing ExpressRoute circuits or purchase one in the Azure portal.
 
-Once linked with Global Reach, the two ExpressRoute circuits will route network traffic between your on-premises environments and your private cloud. The on-premises to private cloud interconnectivity is shown in the following diagram. The interconnectivity represented in the diagram enables the following use cases:
+Once linked with Global Reach, the two ExpressRoute circuits will route network traffic between your on-premises environments and your private cloud. The on-premises to private cloud interconnectivity is shown in the preceding diagram. The interconnectivity represented in the diagram enables the following use cases:
 
 - Hot/Cold Cross-vCenter vMotion
 - On-Premise to AVS private cloud management access
 
 To enable full connectivity, an Authorization Key and private peering ID for Global Reach can be requested in the Azure portal. You use the key and ID to establish Global Reach between an ExpressRoute circuit in your subscription and the ExpressRoute circuit for your new private cloud. The [tutorial for creating a private cloud](tutorial-create-private-cloud.md) provides you with the procedures for requesting and using the key and ID.
 
-The routing requirements of the solution require you to plan private cloud network address spaces so that you avoid overlaps with other virtual networks and on-premises networks. A /22 network block used for each private cloud needs to be unique across your routing domains. This network block includes management and production networks in the private cloud.
+The routing requirements of the solution require you to plan private cloud network address spaces so that you avoid overlaps with other virtual networks and on-premises networks. AVS private clouds require a minimum of a `/22` CIDR network address block for subnets, shown below. This network complements your on-premises networks. In order to connect to on-premises environments and virtual networks, this must be a non-overlapping network address block.
+
+Example `/22` CIDR network address block:  `10.10.0.0/22`
+
+The subnets:
+
+| Network usage             | Subnet | Example        |
+| ------------------------- | ------ | -------------- |
+| Private cloud management            | `/24`    | `10.10.0.0/24`   |
+| vMotion network       | `/24`    | `10.10.1.0/24`   |
+| VM workloads | `/24`   | `10.10.2.0/24`   |
+| ExpressRoute peering | `/24`    | `10.10.3.8/30`   |
 
 ## Next steps 
 
diff --git a/articles/azure-vmware/concepts-private-clouds-clusters.md b/articles/azure-vmware/concepts-private-clouds-clusters.md
@@ -29,14 +29,11 @@ You create, delete, and scale clusters through the portal or API. You still use
 
 ## Hosts
 
-Hyper-converged, bare-metal infrastructure nodes are used in AVS private cloud clusters. There are two types of hosts, and clusters are built using only one type of host. The RAM, CPU, and disk capacities of both types the host types is provided in the table below. 
+Hyper-converged, bare-metal infrastructure nodes are used in AVS private cloud clusters. The RAM, CPU, and disk capacities of the host is provided in the table below. 
 
 | Host Type              |             CPU             |   RAM (GB)   |  vSAN NVMe cache Tier (TB, raw)  |  vSAN SSD capacity tier (TB, raw)  |
 | :---                   |            :---:            |    :---:     |               :---:              |                :---:               |
 | High-End (HE)          |  dual Intel 18 core 2.3 GHz  |     576      |                3.2               |                15.20               |
-| General-Purpose (GP)   |  dual Intel 10 core 2.2 GHz  |     192      |                1.6               |                 7.68               |
-
-Multiple types of hosts provide you with the flexibility to match hosts and cluster specifications to workload and business requirements.
 
 Hosts that are used to build or scale clusters are acquired from an isolated pool of hosts. Those hosts have passed hardware tests and have had all data securely deleted from the flash disks. When you remove a host from a cluster, the internal disks are securely wiped and the hosts are placed into the isolated pool of hosts. When you add a host to a cluster, a sanitized host from the isolated pool is used.
 
diff --git a/articles/azure-vmware/concepts-storage.md b/articles/azure-vmware/concepts-storage.md
@@ -11,12 +11,7 @@ AVS private clouds provide native, cluster-wide storage with VMware vSAN. All lo
 
 ## vSAN clusters
 
-Local storage in each cluster host is used as part of a vSAN datastore. There are two diskgroups, one for High-End (HE) hosts and one for general purpose hosts. All diskgroups use an NVMe cache tier of 1.6 TB with the raw, per host, SSD-based capacity shown in the table below. The size of the raw capacity tier of a cluster is the per host capacity times the number of hosts. For example, a four host cluster of HE hosts will provide 61.6-TB raw capacity in the vSAN capacity tier.
-
-| Host type                   |  Raw SSD capacity |
-| :---                        |       :---:       |
-| High-end                    |      15.4 TB       |
-| General-purpose             |       7.7 TB       |
+Local storage in each cluster host is used as part of a vSAN datastore. All diskgroups use an NVMe cache tier of 1.6 TB with the raw, per host, SSD-based capacity of 15.4 TB. The size of the raw capacity tier of a cluster is the per host capacity times the number of hosts. For example, a four host cluster will provide 61.6-TB raw capacity in the vSAN capacity tier.
 
 Local storage in cluster hosts is used in cluster-wide vSAN datastore. All datastores are created as part of a private cloud deployment and are available for use immediately. The cloudadmin user and all users in the CloudAdmin group can manage datastores with these vSAN privileges:
 - Datastore.AllocateSpace
diff --git a/articles/azure-vmware/faq.md b/articles/azure-vmware/faq.md
@@ -56,23 +56,19 @@ Updates made to the service itself will follow Microsoft Azure’s standard chan
 
 **Is there more than one type of host available?**
 
-There are two types of hosts available: General Purpose and High-end servers.
+There is only one type of host available.
 
 **What are the CPU specifications in each type of host?**
 
-The High-End servers have dual 18 core 2.3 GHz Intel CPUs.
-
-The General Purpose servers have dual 10 core 2.2 GHz Intel CPUs.
+The servers have dual 18 core 2.3 GHz Intel CPUs.
 
 **How much memory is in each host?**
 
-The High-End servers have 576 GB of RAM and the General Purpose hosts have 192 GB RAM.
+The servers have 576 GB of RAM.
 
 **What is the storage capacity of each host?**
 
-Each High-end ESXi host has two VSAN diskgroups with a capacity tier of 15.2 TB and a 3.2 TB NVMe cache tier (1.6 TB in each diskgroup).
-
-The General-purpose ESXi hosts have two VSAN diskgroups with a capacity tier of 7.68 TB and a 1.6 TB NVMe cache tier (1.6 TB in each diskgroup).
+Each ESXi host has two VSAN diskgroups with a capacity tier of 15.2 TB and a 3.2 TB NVMe cache tier (1.6 TB in each diskgroup).
 
 **How much network bandwidth is available in each ESXi host?**
 
@@ -88,10 +84,6 @@ Yes, all VSAN data is encrypted by default using keys stored in Azure Key Vault.
 
 No, private cloud hosts and clusters are dedicated and securely erased before and after use.
 
-**Can I mix host types in a cluster?**
-
-No. General Purpose and High-end hosts can't be mixed in a cluster, though clusters of different host types can be used in a private cloud.
-
 **What are the minimum and maximum number of hosts per cluster?**
 
 Clusters can scale between 3 and 16 ESXi hosts. Trial clusters are limited to three hosts.
diff --git a/articles/azure-vmware/introduction.md b/articles/azure-vmware/introduction.md
@@ -17,7 +17,7 @@ The following diagram shows the adjacency between private clouds and VNets in Az
 
 ## Hosts, clusters, and private clouds
 
-AVS private clouds and clusters are built from one of two types of bare-metal, hyper-converged Azure infrastructure hosts. A general-purpose (GP) host configuration is available for evaluation clusters, and a high-end (HE) host configuration is available for any use case. The high-end hosts have 576-GB RAM and dual Intel 18 core, 2.3-GHz processors. The HE hosts have two vSAN diskgroups with a total 15.36 TB (SSD) raw vSAN capacity tier, and a 3.2 TB (NVMe) vSAN cache tier. General-purpose hosts have 192-GB RAM and dual Intel 10 core, 2.2-GHz processors. The GP hosts have a single vSAN diskgroup with a total 7.68 TB (SSD) raw vSAN capacity tier, and a 1.6 TB (NVMe) vSAN cache tier.
+AVS private clouds and clusters are built from a bare-metal, hyper-converged Azure infrastructure host. The high-end hosts have 576-GB RAM and dual Intel 18 core, 2.3-GHz processors. The HE hosts have two vSAN diskgroups with a total 15.36 TB (SSD) raw vSAN capacity tier, and a 3.2 TB (NVMe) vSAN cache tier.
 
 New private clouds are deployed through the Azure portal or Azure CLI.
 
