Update create-placement-policy.md

Author: Suzi Zuber

articles/azure-vmware/create-placement-policy.md

@@ -3,7 +3,8 @@ title: Create placement policy
 description: Learn how to create a placement policy in Azure VMware Solution to control the placement of virtual machines (VMs) on hosts within a cluster through the Azure portal.
 ms.topic: how-to 
 ms.service: azure-vmware
-ms.date: 04/07/2022
+ms.date: 12/07/2023
+ms.custom: engagement-fy23
 
 #Customer intent: As an Azure service administrator, I want to control the placement of virtual machines on hosts within a cluster in my private cloud. 
 
@@ -16,19 +17,19 @@ In Azure VMware Solution, clusters in a private cloud are a managed resource. As
 The placement policy feature is available in all Azure VMware Solution regions. 
 Placement policies let you control the placement of virtual machines (VMs) on hosts within a cluster through the Azure portal. 
 When you create a placement policy, it includes a DRS rule in the specified vSphere cluster. 
-It also includes additional logic for interoperability with Azure VMware Solution operations.
+It also includes other logic for interoperability with Azure VMware Solution operations.
 
 A placement policy has at least five required components: 
 
 - **Name** - Defines the name of the policy and is subject to the naming constraints of [Azure Resources](../azure-resource-manager/management/resource-name-rules.md).
 
 - **Type** - Defines the type of control you want to apply to the resources contained in the policy.
 
-- **Cluster** - Defines the cluster for the policy. The scope of a placement policy is a vSphere cluster, so only resources from the same cluster may be part of the same placement policy.
+- **Cluster** - Defines the cluster for the policy. The scope of a placement policy is a vSphere cluster, so only resources from the same cluster can be part of the same placement policy.
 
-- **State** - Defines if the policy is enabled or disabled. In certain scenarios, a policy might be disabled automatically when a conflicting rule gets created. For more information, see [Considerations](#considerations) below.
+- **State** - Defines if the policy is enabled or disabled. In certain scenarios, a policy might be disabled automatically when a conflicting rule gets created. For more information, see [Considerations](#considerations).
 
-- **Virtual machine** - Defines the VMs and hosts for the policy. Depending on the type of rule you create, your policy may require you to specify some number of VMs and hosts. For more information, see [Placement policy types](#placement-policy-types) below.
+- **Virtual machine** - Defines the VMs and hosts for the policy. Depending on the type of rule you create, your policy might require you to specify some number of VMs and hosts. For more information, see [Placement policy types](#placement-policy-types).
 
 
 ## Prerequisite
@@ -51,15 +52,15 @@ The assignment of hosts isn't required or permitted for this policy type.
 
 ### VM-Host policies
 
-**VM-Host** policies specify if selected VMs can run on selected hosts.  To avoid interference with platform-managed operations such as host maintenance mode and host replacement, **VM-Host** policies in Azure VMware Solution are always preferential (also known as "should" rules). Accordingly, **VM-Host** policies [may not be honored in certain scenarios](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-793013E2-0976-43B7-9A00-340FA76859D0.html). For more information, see [Monitor the operation of a policy](#monitor-the-operation-of-a-policy) below.
+**VM-Host** policies specify if selected VMs can run on selected hosts.  To avoid interference with platform-managed operations such as host maintenance mode and host replacement, **VM-Host** policies in Azure VMware Solution are always preferential (also known as "should" rules). Accordingly, **VM-Host** policies [may not be honored in certain scenarios](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-793013E2-0976-43B7-9A00-340FA76859D0.html). For more information, see [Monitor the operation of a policy](#monitor-the-operation-of-a-policy).
 
-Certain platform operations dynamically update the list of hosts defined in **VM-Host** policies. For example, when you delete a host that is a member of a placement policy, the host is removed if more than one host is part of that policy. Also, if a host is part of a policy and needs to be replaced as part of a platform-managed operation, the policy is updated dynamically with the new host.
+Certain platform operations dynamically update the list of hosts defined in **VM-Host** policies. For example, when you delete a host that is a member of a placement policy, the host is removed when more than one host is part of that policy. Also, if a host is part of a policy and needs to be replaced as part of a platform-managed operation, the policy is updated dynamically with the new host.
 
 In addition to choosing a name and cluster for the policy, a **VM-Host** policy requires that you select at least one VM and one host to assign to the policy.
 
 - **VM-Host Affinity** policies instruct DRS to try running the specified VMs on the hosts defined.
 
-- **VM-Host Anti-Affinity** policies instruct DRS to try running the specified VMs on hosts other than those defined.
+- **VM-Host Anti-Affinity** policies instruct DRS to try running the specified VMs on hosts other than the ones defined.
 
 
 ## Considerations
@@ -70,18 +71,18 @@ Azure VMware Solution attempts to prevent certain DRS rule violations from occur
 
 You can't remove the last host from a VM-Host policy. However, if you need to remove the last host from the policy, you can remediate it by adding another host to the policy before removing the host from the cluster. Alternatively, you can delete the placement policy before removing the host.
 
-You can't have a VM-VM Anti Affinity policy with more VMs than the number of hosts in a cluster. If removing a host would result in fewer hosts in the cluster than VMs, you'll receive an error preventing the operation. You can remediate it by first removing VMs from the rule and then removing the host from the cluster.
+You can't have a VM-VM Anti Affinity policy with more VMs than the number of hosts in a cluster. If removing a host results in fewer hosts in the cluster than VMs, you receive an error preventing the operation. You can remediate it by first removing VMs from the rule and then removing the host from the cluster.
 
 
 ### Rule conflicts
 
-If DRS rule conflicts are detected when you create a VM-VM policy, it results in that policy being created in a disabled state following standard [VMware DRS Rule behavior](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-69C738B6-5FC8-4189-9CB5-DD90A5A05979.html). For more information on viewing rule conflicts, see [Monitor the operation of a policy](#monitor-the-operation-of-a-policy) below.
+If DRS rule conflicts are detected when you create a VM-VM policy, it results in that policy being created in a disabled state following standard [VMware DRS Rule behavior](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-69C738B6-5FC8-4189-9CB5-DD90A5A05979.html). For more information on viewing rule conflicts, see [Monitor the operation of a policy](#monitor-the-operation-of-a-policy).
 
 
 
 ## Create a placement policy
 
-There is no defined limit to the number of policies that you create. However, the more placement constraints you create, the more challenging it is for vSphere DRS to effectively move virtual machines within the cluster and provide the resources needed by the workloads.      
+There's no defined limit to the number of policies that you create. However, the more placement constraints you create, the more challenging it is for vSphere DRS to effectively move virtual machines within the cluster and provide the resources needed by the workloads.      
 
 Make sure to review the requirements for the [policy type](#placement-policy-types).
 
@@ -111,15 +112,15 @@ Make sure to review the requirements for the [policy type](#placement-policy-typ
    >[!NOTE]
    >The select hosts pane shows how many VM-Host policies are associated with the host and the total number of VMs contained in those associated policies. 
 
-1. Once you've finished adding the VMs you want, select **Add virtual machines**. 
+1. Once you finish adding the VMs you want, select **Add virtual machines**. 
 
 1. Select **Next: Review and create** to review your policy. 
 
 1. Select **Create policy**. If you want to make changes, select **Back: Basics**.
 
 1. After the placement policy gets created, select **Refresh** to see it in the list.
 
-:::image type="content" source="media/placement-policies/create-placement-policy-8.png" alt-text="Screenshot showing the placement policy as Enabled after it's created." lightbox="media/placement-policies/create-placement-policy-8.png":::
+:::image type="content" source="media/placement-policies/create-placement-policy-8.png" alt-text="Screenshot showing the placement policy as Enabled after it gets created." lightbox="media/placement-policies/create-placement-policy-8.png":::
 
 
 ## Edit a placement policy
@@ -178,31 +179,31 @@ Additionally, you can monitor various DRS rule operations, such as recommendatio
 
 ## Restrict VM Movement
 
-For certain extremely sensitive applications vMotion may cause unexpected service interruptions or disruptions. 
-For these types of applications, it may be desirable to restrict VM movement to manually-initiated vMotion only. 
+For certain sensitive applications, vMotion can cause unexpected service interruptions or disruptions. 
+For these types of applications, it might be preferred to restrict VM movement to manually initiated vMotion only. 
 With the Restrict VM movement Placement Policy, DRS-initiated vMotions can be disabled. 
-For most workloads this is not necessary and may cause unintended performance impacts due to noisy neighbors on the same host. 
+For most workloads, this isn't necessary and can cause unintended performance impacts due to noisy neighbors on the same host. 
 
-### Enable Restricted VM movement for specific VMs
+### Enable Restrict VM movement for specific VMs
 
-1. Navigate to Manage Placement policies and click Restrict VM movement. 
-1. Select the VM or VMs you want to restrict, then click Select.
+1. Navigate to Manage Placement policies and select Restrict VM movement. 
+1. Select the VM or VMs you want to restrict, then select Select.
 1. The VM or VMS you selected appears in the VMs with restricted movement tab.   
-In the vSphere Client, a VM override will be created to set DRS to partially automated for that VM.    
+In the vSphere Client, a VM override is created to set DRS to *partially automated* for that VM.    
 DRS will no longer migrate the VM automatically.    
-Manual vMotion of the VM and automatic initial placement of the VM will continue to function.  
+Manual vMotion of the VM and automatic initial placement of the VM continues to function.  
 
 ## FAQs
 
 ### Are placement policies the same as DRS affinity rules?
-Yes, and no. While vSphere DRS implements the current set of policies, we have simplified the experience. Modifying VM groups and Host groups are a cumbersome operation, especially as hosts are ephemeral in nature and could be replaced in a cloud environment. As hosts are replaced in the vSphere inventory in an on-premises environment, the vSphere admin must modify the host group to ensure that the desired VM-Host placement constraints remain in effect. Placement policies in Azure VMware Solution update the Host groups when a host is rotated or changed. Similarly, if you scale in a cluster, the Host Group is automatically updated, as applicable. This eliminates the overhead of managing the Host Groups for the customer.
+Yes, and no. While vSphere DRS implements the current set of policies, we simplified the experience. Modifying VM groups and Host groups are a cumbersome operation, especially as hosts are ephemeral in nature and could be replaced in a cloud environment. As hosts are replaced in the vSphere inventory in an on-premises environment, the vSphere admin must modify the host group to ensure that the desired VM-Host placement constraints remain in effect. Placement policies in Azure VMware Solution update the Host groups when a host is rotated or changed. Similarly, if you scale in a cluster, the Host Group is automatically updated, as applicable. The automatic update eliminates the overhead of managing the Host Groups for the customer.
 
 
 ### As this is an existing functionality available in vCenter, why can't I use it directly? 
 
-Azure VMware Solution provides a VMware private cloud in Azure. In this managed VMware infrastructure, Microsoft manages the clusters, hosts, datastores, and distributed virtual switches in the private cloud. At the same time, the tenant is responsible for managing the workloads deployed on the private cloud. As a result, the tenant administering the private cloud [does not have the same set of privileges](concepts-identity.md) as available to the VMware administrator in an on-premises deployment. 
+Azure VMware Solution provides a VMware private cloud in Azure. In this managed VMware infrastructure, Microsoft manages the clusters, hosts, datastores, and distributed virtual switches in the private cloud. At the same time, the tenant is responsible for managing the workloads deployed on the private cloud. As a result, the tenant administering the private cloud doesn't have the [same set of privileges](concepts-identity.md) as available to the VMware administrator in an on-premises deployment. 
 
-Further, the lack of the desired granularity in the vSphere privileges presents some challenges when managing the placement of the workloads on the private cloud. For example, vSphere DRS rules commonly used on-premises to define affinity and anti-affinity rules can't be used as-is in an Azure VMware Solution environment, as some of those rules can block day-to-day operation the private cloud. Placement Policies provides a way to define those rules using the Azure VMware Solution portal, thereby circumventing the need to use DRS rules. Coupled with a simplified experience, they also ensure that the rules don't impact the day-to-day infrastructure maintenance and operation activities. 
+Further, the lack of the desired granularity in the vSphere privileges presents some challenges when managing the placement of the workloads on the private cloud. For example, vSphere DRS rules commonly used on-premises to define affinity and anti-affinity rules can't be used as-is in an Azure VMware Solution environment, as some of those rules can block day-to-day operation the private cloud. Placement Policies provides a way to define those rules using the Azure VMware Solution portal, thereby circumventing the need to use DRS rules. Coupled with a simplified experience, Placement Policies ensure the rules don't impact the day-to-day infrastructure maintenance and operation activities. 
 
 ###  What is the difference between the VM-Host affinity policy and Restrict VM movement?
 
@@ -212,7 +213,7 @@ A VM-Host affinity policy is used to restrict the movement of VMs to a group of
 
 The VM-Host **MUST** rules aren't supported because they block maintenance operations. 
 
-VM-Host **SHOULD** rules are preferential rules, where vSphere DRS tries to accommodate the rules to the extent possible. Occasionally, vSphere DRS may vMotion VMs subjected to the VM-Host **SHOULD** rules to ensure that the workloads get the resources they need. It's a standard vSphere DRS behavior, and the Placement policies feature does not change the underlying vSphere DRS behavior.
+VM-Host **SHOULD** rules are preferential rules, where vSphere DRS tries to accommodate the rules to the extent possible. Occasionally, vSphere DRS may vMotion VMs subjected to the VM-Host **SHOULD** rules to ensure that the workloads get the resources they need. It's a standard vSphere DRS behavior, and the Placement policies feature doesn't change the underlying vSphere DRS behavior.
 
-If you create conflicting rules, those conflicts may show up on the vCenter Server, and the newly defined rules may not take effect. It's a standard vSphere DRS behavior, the logs for which can be observed in the vCenter Server.
+If you create conflicting rules, those conflicts can show up on the vCenter Server, and the newly defined rules might not take effect. It's a standard vSphere DRS behavior, the logs for which can be observed in the vCenter Server.