PART-I
PART-II
PART-II
With VMware Storage vMotion, we can migrate a virtual machine metadata files and its disk files from one datastore to another even if the virtual machine is powered ON and running.
The virtual machine does not change ESXi host during Storage vMotion migration, only the virtual machines files are moved from one datastore to another.
 |
| Image: VMware |
Virtual machine file names on the destination datastore are changed to match the inventory name of the virtual machine. The migration process renames all virtual disk, configuration, snapshot, and .nvram files. So if you want to rename any virtual machine, instead renaming directly in vCenter inventory action menu of virtual machine, do it when you are performing Storage vMotion.
NOTE:
If you rename virtual machine directly from vCenter inventory, virtual machine files on datastore are not updated as per new name.
Use Cases:
- We may have to move virtual machines between arrays for maintenance or to upgrade activities.
- In case we want to rename a virtual machine ensuring all files are updated with new name.
- Flexibility to change disk types (Thin/Thick), which you can use to reclaim space while performing Storage vMotion .
- Redistribute virtual machines or virtual disks to different storage volumes to balance capacity or improve performance manually or using SDRS.
Storage vMotion has following requirements and limitations:
- Virtual machine disks must be in persistent mode or be raw device mappings (RDMs).
- Migration of virtual machines during VMware Tools installation is not supported.
- We cannot move virtual disks greater than 2TB from a VMFS5 datastore to a VMFS3 datastore.
- The host on which the virtual machine is running must have a valid license covering Storage vMotion feature.
- The host on which the virtual machine is running must have access to both the source and target datastores.
NOTE:
- In case of RDMs, virtual compatibility mode RDMs, you can migrate the mapping file or convert to thick-provisioned or thin-provisioned disks to VMDK file during migration as long as the destination is not an NFS datastore. If you convert the mapping file, a new virtual disk is created and the contents of the mapped LUN are copied to this disk.
- For physical compatibility mode RDMs, you can migrate the mapping file only.
How Does VMware Storage VMotion Work?
- Before moving a virtual machines disk file, Storage VMotion moves the home directory which contains meta data about the virtual machine (i.e. configuration, swap and log files) to the new location.
- A shadow VM gets started on the destination datastore using the copied files. The shadow VM idles, waiting for the copying of the VM disk files to complete.
- After relocating the home directory, Storage VMotion copies the contents of the virtual machine disk file (.VMDK) to the destination datastore, using “changed block tracking” to maintain data integrity during the migration process.
- In next step, the software queries the changed block tracking module to determine what regions of the disk were written to during the first iteration, and then performs a second iteration of copy, where those regions that were changed during the first iteration copy.
- Once the process is complete, the virtual machine is quickly suspended and resumed from shadow VM so that it can begin using the virtual machine home directory and disk file on the destination datastore location.
- Before VMware ESXI host allows the virtual machine to start running again, the final changed regions of the source disk are copied over to the destination and the source home and disks are removed.
NOTE:
- If you have VAAI plugin support, files can be moved between two datastores at storage level. This saves ESXi host resources by offloading task to storage devices.
- If no VAAI plugin is available, files will be moved using data mover by ESXi host