Merge pull request #216314 from v-ksreedevan/28Oct-Blackoutwindow

Update regarding Blackout window

Author: prmerger-automator[bot]

articles/migrate/concepts-vmware-agentless-migration.md

@@ -5,7 +5,7 @@ author: anvar-ms
 ms.author: anvar
 ms.manager: bsiva
 ms.topic: conceptual
-ms.date: 05/31/2021
+ms.date: 09/01/2022
 
 ---
 # Azure Migrate agentless migration of VMware virtual machines
@@ -80,7 +80,7 @@ There are two stages in every replication cycle that ensures data integrity betw
 1. First, we validate if every sector that has changed in the source disk is replicated to the target disk. Validation is performed using bitmaps.
 Source disk is divided into sectors of 512 bytes. Every sector in the source disk is mapped to a bit in the bitmap. When data replication starts, bitmap is created for all the changed blocks (in delta cycle) in the source disk that needs to be replicated. Similarly, when the data is transferred to the target Azure disk, a bitmap is created. Once the data transfer completes successfully, the cloud service compares the two bitmaps to ensure no changed block is missed. In case there's any mismatch between the bitmaps, the cycle is considered failed. As every cycle is resynchronization, the mismatch will be fixed in the next cycle.
 
-1. Next we ensure that the data that's transferred to the Azure disks is the same as the data that was replicated from the source disks. Every changed block that is uploaded is compressed and encrypted before it's written as a blob in the log storage account. We compute the checksum of this block before compression. This checksum is stored as metadata along with the compressed data. Upon decompression, the checksum for the data is calculated and compared with the checksum computed in the source environment. If there's a mismatch, the data is not written to the Azure disks, and the cycle is considered failed. As every cycle is resynchronization, the mismatch will be fixed in the next cycle.
+1. Next we ensure that the data that's transferred to the Azure disks is the same as the data that was replicated from the source disks. Every changed block that is uploaded is compressed and encrypted before it's written as a blob in the log storage account. We compute the checksum of this block before compression. This checksum is stored as metadata along with the compressed data. Upon decompression, the checksum for the data is calculated and compared with the checksum computed in the source environment. If there's a mismatch, the data isn't written to the Azure disks, and the cycle is considered failed. As every cycle is resynchronization, the mismatch will be fixed in the next cycle.
 
 ## Security
 
@@ -91,7 +91,7 @@ The Azure Migrate appliance compresses data and encrypts before uploading. Data
 When a VM undergoes replication (data copy), there are a few possible states:
 - **Initial replication queued**: The VM is queued for replication (or migration) as there may be other VMs that are consuming the on-premises resources (during replication or migration). Once the resources are free, this VM will be processed.
 - **Initial replication in progress**: The VM is being scheduled for initial replication. 
-- **Initial replication**: The VM is undergoing initial replication. When the VM is undergoing initial replication, you cannot proceed with test migration and migration. You can only stop replication at this stage.
+- **Initial replication**: The VM is undergoing initial replication. When the VM is undergoing initial replication, you can't proceed with test migration and migration. You can only stop replication at this stage.
 - **Initial replication (x%)**: The initial replication is active and has progressed by x%. 
 - **Delta sync**: The VM may be undergoing a delta replication cycle that replicates the remaining data churn since the last replication cycle.
 - **Pause in progress**: The VM is undergoing an active delta replication cycle and will be paused in some time.  
@@ -104,8 +104,8 @@ When a VM undergoes replication (data copy), there are a few possible states:
 
 ### Other states
 
-- **Initial replication failed**: The initial data could not be copied for the VM. Follow the remediation guidance to resolve. 
-- **Repair pending**: There was an issue in the replication cycle.  You can select the link to understand possible causes and actions to remediate (as applicable). If you had opted for **Automatically repair replication** by selecting **Yes** when you triggered replication of VM, the tool will try to repair it for you. Else, select the VM, and select **Repair Replication**. If you did not opt for **Automatically repair replication** or if the above step did not work for you, then stop replication for the virtual machine, reset the changed block tracking on the virtual machine, and then reconfigure the replication.
+- **Initial replication failed**: The initial data couldn't be copied for the VM. Follow the remediation guidance to resolve. 
+- **Repair pending**: There was an issue in the replication cycle.  You can select the link to understand possible causes and actions to remediate (as applicable). If you had opted for **Automatically repair replication** by selecting **Yes** when you triggered replication of VM, the tool will try to repair it for you. Else, select the VM, and select **Repair Replication**. If you didn't opt for **Automatically repair replication** or if the above step didn't work for you, then stop replication for the virtual machine, reset the changed block tracking on the virtual machine, and then reconfigure the replication.
 - **Repair replication queued**: The VM is queued for replication repair as there are other VMs that are consuming the on-premises resources. Once the resources are free, the VM will be processed for repair replication.
 - **Resync (x%)**: The VM is undergoing a data resynchronization. This can happen if there was some issue / mismatch during data replication. 
 - **Stop replication/complete migration failed**: Select the link to understand the possible causes for failure and actions to remediate (as applicable).
@@ -131,7 +131,7 @@ When a VM undergoes replication (data copy), there are a few possible states:
 
 ## Scheduling logic
 
-Initial replication is scheduled when replication is configured for a VM. It is followed by incremental replications (delta replications).
+Initial replication is scheduled when replication is configured for a VM. It's followed by incremental replications (delta replications).
 
 Delta replication cycles are scheduled as follows:
 
@@ -151,7 +151,7 @@ That is, next delta replication will be scheduled no sooner than one hour. For e
 - Ongoing VM replications are prioritized over scheduled replications (new replications)
 - Pre-failover (on-demand delta replication) cycle has the highest priority followed by initial replication cycle. Delta replication cycle has the least priority.
 
-That is, whenever a migrate operation is triggered, the on-demand replication cycle for the VM is scheduled and other ongoing replications take back seat if they are competing for resources.
+That is, whenever a migrate operation is triggered, the on-demand replication cycle for the VM is scheduled and other ongoing replications take back seat if they're competing for resources.
 
 **Constraints:**
 
@@ -163,7 +163,7 @@ We use the following constraints to ensure that we don't exceed the IOPS limits
 
 ## Scale-out replication
 
-Azure Migrate supports concurrent replication of 500 virtual machines. When you are planning to replicate more than 300 virtual machines, you must deploy a scale-out appliance. The scale-out appliance is similar to an Azure Migrate primary appliance but consists only of gateway agent to facilitate data transfer to Azure. The following diagram shows the recommended way to use the scale-out appliance.
+Azure Migrate supports concurrent replication of 500 virtual machines. When you're planning to replicate more than 300 virtual machines, you must deploy a scale-out appliance. The scale-out appliance is similar to an Azure Migrate primary appliance but consists only of gateway agent to facilitate data transfer to Azure. The following diagram shows the recommended way to use the scale-out appliance.
 
 ![Scale-out configuration.](./media/concepts-vmware-agentless-migration/scale-out-configuration.png)
 
@@ -176,7 +176,7 @@ When you stop replication, the intermediate managed disks (seed disks) created d
 
 The VM for which the replication is stopped, can be replicated by enabling replication again. If the VM was migrated, you can resume replication and migration again.
 
-As a best practice, you should always complete the migration after the VM has migrated successfully to Azure to ensure that you don't incur extra charges for storage transactions on the intermediate managed disks (seed disks). In some cases, you will notice that stop replication takes time. It is because whenever you stop replication, the ongoing replication cycle is completed (only when the VM is in delta sync) before deleting the artifacts.
+As a best practice, you should always complete the migration after the VM has migrated successfully to Azure to ensure that you don't incur extra charges for storage transactions on the intermediate managed disks (seed disks). In some cases, you'll notice that stop replication takes time. It's because whenever you stop replication, the ongoing replication cycle is completed (only when the VM is in delta sync) before deleting the artifacts.
 
 ## Impact of churn
 
@@ -190,7 +190,7 @@ You can increase or decrease the replication bandwidth using the _NetQosPolicy._
 
 You could create a policy on the Azure Migrate appliance to throttle replication traffic from the appliance by creating a policy such as this one:
 
-`New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB`
+```New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB```
 
 > [!NOTE]
 > This is applicable to all the replicating VMs from the Azure Migrate appliance simultaneously.
@@ -202,7 +202,8 @@ You can also increase and decrease replication bandwidth based on a schedule usi
 Azure Migrate provides a configuration-based mechanism through which customers can specify the time interval during which they don't want any replications to proceed. This time interval is called the blackout window. The need for a blackout window can arise in multiple scenarios such as when the source environment is resource constrained or when customers want replication to go through only during non-business hours, etc.
 
 > [!NOTE]
-> The existing replication cycles at the start of the blackout window will complete before the replication pauses.
+> - The existing replication cycles at the start of the blackout window will complete before the replication pauses.
+> - For any migration initiated during the blackout window, the final replication will not run, causing the migration to fail.
 
 A blackout window can be specified for the appliance by creating/updating the file GatewayDataWorker.json in C:\ProgramData\Microsoft Azure\Config. A typical file would be of the form: