Acrloinx edits

Author: v-ksreedevan

articles/migrate/prepare-for-agentless-migration.md

@@ -13,8 +13,8 @@ ms.custom: engagement-fy23
 
 This article provides an overview of the changes performed when you [migrate VMware VMs to Azure via the agentless migration](./tutorial-migrate-vmware.md) method using the Migration and modernization tool.
 
-Before you migrate your on-premises VM to Azure, you may require a few changes to make the VM ready for Azure. These changes are important to ensure that the migrated VM can boot successfully in Azure and connectivity to the Azure VM can be established.
-Azure Migrate automatically handles these configuration changes for the operating system versions mentioned below for both Linux and Windows. This process is called *Hydration*.
+Before you migrate your on-premises VM to Azure, you may require a few changes to make the VM ready for Azure. These changes are important to ensure that the migrated VM can boot successfully in Azure and connectivity to the Azure VM can be established-.
+Azure Migrate automatically handles these configuration changes for the following operating system versions for both Linux and Windows. This process is called *Hydration*.
 
 **Operating system versions supported for hydration**
 
@@ -35,12 +35,12 @@ You can also use this article to manually prepare the VMs for migration to Azure
 
 ## Hydration process
 
-You have to make some changes to the VMs configuration before the migration to ensure that the migrated VMs function properly on Azure. Azure Migrate handles these configuration changes via the *hydration* process. The hydration process is only performed for the versions of Azure supported operating systems given above. Before you migrate, you may need to perform the required changes manually for other operating system versions that are not listed above. If the VM is migrated without the required changes, the VM may not boot, or you may not have connectivity to the migrated VM. The following diagram shows you that Azure Migrate performs the hydration process.
+You have to make some changes to the VMs configuration before the migration to ensure that the migrated VMs function properly on Azure. Azure Migrate handles these configuration changes via the *hydration* process. The hydration process is only performed for the versions of Azure supported operating systems given above. Before you migrate, you may need to perform the required changes manually for other operating system versions that aren't listed above. If the VM is migrated without the required changes, the VM may not boot, or you may not have connectivity to the migrated VM. The following diagram shows you that Azure Migrate performs the hydration process.
 
  [![Hydration steps](./media/concepts-prepare-vmware-agentless-migration/hydration-process-inline.png)](./media/concepts-prepare-vmware-agentless-migration/hydration-process-expanded.png#lightbox)
 
 When a user triggers *Test Migrate* or *Migrate*, Azure Migrate performs the hydration process to prepare the on-premises VM for migration to Azure.
-To set up the hydration process, Azure Migrate creates a temporary Azure VM and attaches the disks of the source VM to perform changes to make the source VM ready for Azure. The temporary Azure VM is an intermediate VM created during the migration process before the final migrated VM is created. The temporary VM will be created with a similar OS type (Windows/Linux) using one of the marketplace OS images. If the on-premises VM is running Windows, the operating system disk of the on-premises VM will be attached as a data disk to the temporary VM for performing changes. If it is a Linux server, all the disks attached to the on-premises VM will be attached as data disks to the temporary Azure VM.
+To set up the hydration process, Azure Migrate creates a temporary Azure VM and attaches the disks of the source VM to perform changes to make the source VM ready for Azure. The temporary Azure VM is an intermediate VM created during the migration process before the final migrated VM is created. The temporary VM will be created with a similar OS type (Windows/Linux) using one of the marketplace OS images. If the on-premises VM is running Windows, the operating system disk of the on-premises VM will be attached as a data disk to the temporary VM for performing changes. If it's a Linux server, all the disks attached to the on-premises VM will be attached as data disks to the temporary Azure VM.
 
 Azure Migrate will create the network interface, a new virtual network, subnet, and a network security group (NSG) to host the temporary VM. These resources are created in the customer's subscription. If there are conflicting policies that prevent the creation of the network artifacts, Azure Migrate will attempt to create the temporary Azure VM in the virtual network and subnet provided as part of the replication target settings options.
 
@@ -62,15 +62,15 @@ The preparation script executes the following changes based on the OS type of th
    - Mounts each partition on the OS disk attached to the temporary VM.
 
    - Looks for \Windows\System32\Config\System registry files after mounting the partition.
-   - If the files are not found, the partition is unmounted, and the search continues for the correct partition.
-   - If the files are not present on any of the partitions, it could indicate that an incorrect OS disk was selected, or the OS disk is corrupted. Azure Migrate will fail the migration process with an appropriate error.
+   - If the files aren't found, the partition is unmounted, and the search continues for the correct partition.
+   - If the files aren't present on any of the partitions, it could indicate that an incorrect OS disk was selected, or the OS disk is corrupted. Azure Migrate will fail the migration process with an appropriate error.
 
    >[!NOTE]
-   >This step is not relevant if you’re manually preparing the servers for migration.
+   >This step isn't relevant if you’re manually preparing the servers for migration.
 
 1. **Make boot and connectivity related changes**
 
-   After the source OS volume files are detected, the preparation script will load the SYSTEM registry hive into the registry editor of the temporary Azure VM and perform the following changes to ensure VM boot up and connectivity. You need to configure these settings manually if the OS version is not supported for hydration.
+   After the source OS volume files are detected, the preparation script will load the SYSTEM registry hive into the registry editor of the temporary Azure VM and perform the following changes to ensure VM boot up and connectivity. You need to configure these settings manually if the OS version isn't supported for hydration.
 
    1. **Validate the presence of the required drivers**
 
@@ -114,7 +114,7 @@ The preparation script executes the following changes based on the OS type of th
 
 1. **Disable VMware Tools**
 
-   Make “VMware Tools” service start-type to disabled if it exists as they are not required for the VM in Azure.
+   Make “VMware Tools” service start-type to disabled if it exists as they aren't required for the VM in Azure.
 
    >[!NOTE]                        
    >To connect to Windows Server 2003 VMs, Hyper-V Integration Services must be installed on the Azure VM. Windows Server 2003 machines don't have this installed by default. See this [article](./prepare-windows-server-2003-migration.md) to install and prepare for migration.
@@ -142,15 +142,15 @@ The preparation script executes the following changes based on the OS type of th
 
    - Discover /root partition:
      - Mount each visible partition and look for etc/fstab.
-      - If the fstab files are not found, the partition is unmounted, and the search continues for the correct partition.
+      - If the fstab files aren't found, the partition is unmounted, and the search continues for the correct partition.
       - If the fstab files are found, read the fstab content to identify the root device and mount it as the base mount point.
    - Discover /boot and other system partitions:
      - Use fstab content to determine if /boot is a separate partition. If it’s a separate partition, then obtain the boot partition device name from the fstab content or look for the partition, which has the boot flag.
      - The script will proceed to discover and mount /boot, and other necessary partitions on “/mnt/azure_sms_root” to build the root filesystem tree required for chroot jail. Other necessary partitions include: /boot/grub/menu.lst, /boot/grub/grub.conf, /boot/grub2/grub.cfg, /boot/grub/grub.cfg, /boot/efi (for UEFI boot), /var, /lib, /etc, /usr, and others.
 
 1. **Discover OS Version**
 
-   Once the root partition is discovered, the script will use the below files to determine the Linux Operating System distribution and version.
+   Once the root partition is discovered, the script will use the following files to determine the Linux Operating System distribution and version.
 
    - RHEL/CentOS: etc/redhat-release
    - OL: etc/oracle-release
@@ -162,7 +162,7 @@ The preparation script executes the following changes based on the OS type of th
 
    The next step is to inspect the kernel image and rebuild the Linux init image so, that it contains the necessary Hyper-V drivers (**hv_vmbus, hv_storvsc, hv_netvsc**) on the initial ramdisk. Rebuilding the init image ensures that the VM will boot in Azure.
 
-   Azure runs on the Hyper-V hypervisor. So, Linux requires certain kernel modules to run in Azure. To prepare your Linux image, you need to rebuild the initrd so that at least the hv_vmbus and hv_storvsc kernel modules are available on the initial ramdisk. The mechanism for rebuilding the initrd or initramfs image may vary depending on the distribution. Consult your distribution's documentation or support for the proper procedure. Here is one example for rebuilding the initrd by using the mkinitrd utility:
+   Azure runs on the Hyper-V hypervisor. So, Linux requires certain kernel modules to run in Azure. To prepare your Linux image, you need to rebuild the initrd so that at least the hv_vmbus and hv_storvsc kernel modules are available on the initial ramdisk. The mechanism for rebuilding the initrd or initramfs image may vary depending on the distribution. Consult your distribution's documentation or support for the proper procedure. Here's one example for rebuilding the initrd by using the mkinitrd utility:
 
    1. Find the list of kernels installed on the system (/lib/modules)
    1. For each module, inspect if the Hyper-V drivers are already included.
@@ -185,7 +185,7 @@ The preparation script executes the following changes based on the OS type of th
         ```
           sudo mkinitrd --preload=hv_storvsc --preload=hv_vmbus -v -f initrd-`uname -r`.img `uname -r`
         ```
-   Most new versions of Linux distributions have this included by default. If not included, install manually for all versions except those called out above using the aforementioned steps.
+   Most new versions of Linux distributions have this included by default. If not included, install manually for all versions except those called out, using the aforementioned steps.
 
 1. **Enable Azure Serial Console logging**
 
@@ -217,7 +217,7 @@ The preparation script executes the following changes based on the OS type of th
         # sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
       ```
 
-   1. Remove Network Manager if necessary. Network Manager can interfere with the Azure Linux agent for a few OS versions. It is recommended to make these changes for servers running RedHat and Ubuntu distributions.
+   1. Remove Network Manager if necessary. Network Manager can interfere with the Azure Linux agent for a few OS versions. It's recommended to make these changes for servers running RedHat and Ubuntu distributions.
 
    1. Uninstall this package by running the following command:
     
@@ -254,11 +254,11 @@ The preparation script executes the following changes based on the OS type of th
 
 1. **Fstab validation**
 
-    Azure Migrate will validate the entries of the fstab file and replace fstab entries with persistent volume identifiers, UUIDs wherever needed. This ensures the drive/partition name remains constant no matter the system it is attached to.
+    Azure Migrate will validate the entries of the fstab file and replace fstab entries with persistent volume identifiers, UUIDs wherever needed. This ensures the drive/partition name remains constant no matter the system it's attached to.
 
    - If the device name is a standard device name (say /dev/sdb1), then:
-     - If it’s a root or boot partition, then it is replaced with UUID.
-     - If the partition coexists with either the root or boot partition as standard partitions on the same disk, then it is replaced with UUID.
+     - If it’s a root or boot partition, then it's replaced with UUID.
+     - If the partition coexists with either the root or boot partition as standard partitions on the same disk, then it's replaced with UUID.
    - If the device name is UUID/LABEL/LV, then no changes will be done.
    - If it’s a network device (nfs, cifs, smbfs, and etc), then the script will comment the entry. To access it, you can uncomment the same and reboot your Azure VM.