How to migrate VMs with Thick provision disk (Lazy or Eager Zero) from SAN (VMFS) to vSAN Datastore with the same Thick provision disk format

Products

• VMware vSAN

Issue/Introduction

Successfully migrate VMs (Thick Provisioned) from VMFS to vSAN datastore by keeping the status of the VMDK as thick provisioned

Symptoms:
Some applications (e.g., Oracle RAC cluster) need the VM to be Thick Provisioned (Lazy or Eager Zero). By default, the vSAN datastore will be thin provisioned. If the customer is migrating existing "Thick Provisioned" disks (which can be either Lazy or Eager Zero) from a traditional SAN VMFS datastore to a vSAN datastore, the destination VM by default will be thin provisioned. You may see if the VM is "thick" or "thin" in the web client: VM > Summary > VM Hardware > Hard Disk in the web client.

The customer may face the following issues:

• Cannot migrate VMs with thick provisioned disks from the SAN (VMFS) to the vSAN as the disk format option in the advanced settings of Storage vMotion (both XvMotion and SvMotion) is grayed out.
• The VMs are converted to "Thin disk" upon migration regardless of the state they had prior to a storage migration. 
• New VM provisioning works with thick disks on vSAN, however, XvMotion and SvMotion from SAN to vSAN convert the disks to thin.
• Configuring the vSAN policy to an Object Space Reservation of 100% does not change the disk from thin to thick provisioned.

Environment

VMware vSAN 8.0

VMware vSAN 6.7.x
VMware vSAN 6.6.x
VMware vSAN 6.x

Cause

This feature is blocked from the UI perspective (vSphere client and HTML client) for the vCenter server when the vSAN datastore is chosen as the target.

Resolution

The engineering team has provided a python script to achieve SvMotion and XvMotion of VMs within the same vCenter server. This script works only within the same vCenter and does not work across multiple vCenter servers. The script does not make any changes to the source VM; however, as a best practice, VMware recommends having backups of the VM. Customers will need to use the PowerCLI scripts to migrate between vCenter servers.

Sample: 

• Please note double quotes (") are not permitted, and singles quotes (') must be used.
• The names of the vCenter VM Cluster and Datastore should match, and they are case-sensitive.
• The relocate python script will initiate the task "Relocate virtual machine" and this will be shown as a task in vCenter's recent tasks along with the progress bar.

Steps :
1. Upload the script to vCenter Server (Check the Attachment: RelocateVM.py) in /tmp folder. The script is attached to the KB.
2. Validate the integrity of the script by using the below "cksum" command after uploading it to vCenter.
3. VMware recommends running the steps below on a small test VM and validating the results.

#cksum /tmp/RelocateVM.py
2479068796 7548 /tmp/RelocateVM.py

3. Run python script on vCenter server
 
Usage: RelocateVM.py [-h] [-s HOST] [-u USER] [-p PASSWORD] [-c CLUSTER_NAME]
                     [-t TARGETHOST] [-d DATASTORENAME] [-k VMS] [-r RP]
                     [-P PROVISIONTYPE]
                     action
The purpose of this tool is to migrate a virtual machine from a non-vSAN datastore to a vSAN datastore and change the disk provisioning type. The script must be ran on the vCenter Server.

Positional arguments:

action                Now the following actions are supported: 'listVMs' 'relocate_vm' (Migrate virtual machine with type 'Change both compute resource and storage'.
                      If '-- targetHost' is specified, compute resource will be migrated to the target host)

optional arguments:
  -h, --help                                          Show this help message and exit -s HOST, --vcHost HOST VC host to connect. (Required)
  -u USER, --user USER                                User name of vc host. (Default: '[email protected]')
  -p PASSWORD, --password PASSWORD                    Password of vc host.
  -c CLUSTER_NAME, --clusterName                      CLUSTER_NAME Specify the cluster need to detect. (Default: 'VSAN-Cluster')
  -t TARGETHOST, --targetHost TARGETHOST              Migrate the virtual machine to a specific host or cluster
  -d DATASTORENAME, --datastore DATASTORENAME         Specify the destination datastore. (Default: 'vsanDatastore')
  -k VMS, --vm VMS                                    Specify the VM name need to be relocated. Sample: --vms vm1,vm2
-r RP, --resourcepool RP
                        Specify the destination resource pool. Sample:
                        --resourcepool 'rp1'. Relocate to cluster only if no
                        resource pool is specified
-P PROVISIONTYPE, --provisionType PROVISIONTYPE
                        Virtual disk provision type, supports: thin, thick; if
                        omitted, thick will be taken

# python /tmp/RelocateVM.py -s <VCIP/localhost> -p <vCemterPassword> -c <Name of Destination vSAN cluster> -k <VM_name_source_cluster> -t <destination_host> -d <datastorename/vsandatastore> relocate_vm -P thick

Sample command from LAB for ex. 

# python /tmp/RelocateVM.py -s localhost -p '*****' -c 'Production_ALL_flash' -k 'Thick_vm-1' -t 'ESXI.test.local' -d 'vsanDatastore' relocate_vm  -P thick

Total cluster number: 1
Production_ALL_flash, vSAN enabled: True
Virtual Mainchines in cluster: ['Thick_vm-1', 'sddc-analyzer-clone', 'Win-Cluster-2k19-H2', 'Win-cluster-2k19-H1', 'RDP-New', 'server2012', 'SRM-Primary', 'P_VC_SRM.vsensei.local', 'hytrust-Secondary', 'vijESX!3', 'VijESXI1', 'p-h3.vsensei.local', 'p-h1.vsensei.local', 'zerto-host-2', 'zerto-host-1', 'zerto-mgmt_srm-1', 'zerto-primary-vc', 'enc-h2', 'HCIBench_1.6.7.1', 'S_VC_SRM.vsensei.local', 'LAMP-Host-production', 'zerto-host-4', 'zerto-host-6', 'p-ad-vsensei.local', 'zerto-secondary-vc', 'enc-h3', 's-h3.vsensei.local', 'VijESXI4', 'enc-h1', 'Ubuntu-Dcoker', 'zerto-mgr-SRM_2', 'VMware-vRealize-Log-Insight-4.7.0', 'SRM-Secondary', 'VijayVCSA6.5', 'vSAN_Perf_Monitor', 's-h1.vsensei.local', 'vijayserver2012', 'VCSA_embd_mgmt', 'p-h2.vsensei.local', 'vmware-ioinsight-1.1.1', 'enc-h4', 'hytrust-Primary', 's-h2.vsensei.local', 'SDDC_Analyzer', 'VijESXI2', 'zerto-host-3']



8.0 

Syntax:
python RelocateVM.py -s <vcenter_ip> -p '******' -c <CLUSTER_NAME> -k <VM_NAME> -t <HOST_IP> -d <Target_vSAN_Datastore_name> relocate_vm -P <desired_provisioning_type>

Sample command:

root@test [ /tmp ]# python RelocateVM.py -s localhost -p FIFY4+.DmvMh8xkg  -c 'VSAN-Cluster' -k 'VMFS6_LZ' -t <IP_address> -d 'vsanDatastore' relocate_vm -P thin
Sys path: ['/tmp', '/usr/lib/python310.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload', '/usr/lib/python3.10/site-packages', '/usr/lib/vmware-vpx/pyJack/', '/usr/lib/vmware/site-packages/']
Total cluster number: 1
VSAN-Cluster, vSAN enabled: True
Virtual Mainchines in cluster: ['VMFS6_EZ1', 'test-thin', 'VMFS6_EZ', 'VMFS6_LZ', 'vCLS-06bff702-285c-4891-b888-2f54e2042099', 'vCLS-b2131de4-e733-4cad-8409-7e3c4d82e072', 'vCLS-6fe6ec61-2567-4f3a-9ae8-5a576bf5e3b9']
/tmp/RelocateVM.py:166: DeprecationWarning: setDaemon() is deprecated, set the daemon attribute instead
  t.setDaemon(True)

=======

- After migration using RelocateVM.py:

root@sc-rdops-vm13-dhcp-130-120:~] esxcli vsan debug object list --vm-name=VMFS6_LZ
Object UUID: 587b9766-cb2f-6c73-eb8f-020046423d38
   Version: 19
   Health: healthy
   Owner: sc-rdops-vm13-dhcp-143-141.eng.vmware.com
   Size: 10.00 GB
   Used: 0.01 GB
   Used 4K Blocks: 0.00 GB
   Policy:
      stripeWidth: 1
      cacheReservation: 0
      proportionalCapacity: 0 <=======

[root@sc-rdops-vm13-dhcp-130-120:~] /usr/lib/vmware/osfs/bin/objtool getAttr -u 587b9766-cb2f-6c73-eb8f-020046423d38
Object Attributes --

UUID:587b9766-cb2f-6c73-eb8f-020046423d38

Object type:vsan

Group uuid:577b9766-0ab1-0be4-e8b3-020046423d38

Container uuid:(null)

IsSparse:0

Allocation type:Thin <=======

A relocate VM task will be initiated and can be monitored from the UI/vsphere-client .

Workaround:
Customers can also choose to perform the task using powercli.

Additional Information

N/A

Impact/Risks:

Use RelocateVM script for 6.0

Use RelocateVM.py.gz for 8.0
Run the script from the command line on the vCenter server with a test VM prior to using it on production VMs.