29

I'm looking for a good solution to a VMware ESXi environment issue where there's no vCenter available.

What's the best way to move a VM from one datastore to another on a single ESXi host, while maintaining the VMDK thin-provisioning?

This is a standalone server that's been expanded with another drive array/datastore. I'd like to move the data contained in the old array to the new.

Edit: The destination datastore size is actually smaller than the source. I do not have enough room to copy the thick file.

ewwhite
  • 194,921
  • 91
  • 434
  • 799

5 Answers5

31

Just went through finding a way to do this myself. Here's a, hopefully, easy to follow guide on how to move your VM to a new datastore while preserving thin provisioning during the transfer (thus also reducing transfer times):

Step by step guide using vmkfstools in the CLI

  1. Power off VM
  2. (Optional) Consolidate snapshots if needed.
  3. Remove VM from vCenter inventory
  • Right click VM and click "Remove from Inventory" enter image description here
  1. Enable SSH on the ESXi machine
  • In the vSphere client go to: Configuration -> Security profile -> Properties (next to Services) -> SSH (in the list) -> Options -> Start
  1. Log in via SSH as root
  2. Prepare a directory on the destination datastore
  • mkdir "/vmfs/volumes/destination_datastore/Some VM"
  1. Clone the .vmdk files using thin provisioning
  • vmkfstools -i "/vmfs/volumes/source_datastore/Some VM/Some VM.vmdk" -d thin "/vmfs/volumes/destination_datastore/Some VM/Some VM.vmdk"
  1. Copy any remaining files (avoiding overwriting the .vmdk files)
  • find "/vmfs/volumes/source_datastore/Some VM" -maxdepth 1 -type f | grep -v ".vmdk" | while read file; do cp "$file" "/vmfs/volumes/destination_datastore/Some VM"; done
  1. If you did not consolidate snapshots in step 2, there may be snapshot .vmdk delta files, we also need to copy these (this may take some time):
  • find "/vmfs/volumes/source_datastore/Some VM" -maxdepth 1 -type f | grep [0123456789][0123456789][0123456789][0123456789][0123456789][0123456789] | grep ".vmdk" | while read file; do cp "$file" "/vmfs/volumes/destination_datastore/Some VM"; done
  1. Once done cloning and copying all necessary files, add the VM from the new datastore back to inventory
  • In the vSphere client go to: Configuration->Storage->Data Browser, right click the destination datastore which you moved your VM to and click "Browse datastore". enter image description here
  1. Browse to your VM and right click the .vmx file, then click "Add to inventory" enter image description here
  2. Boot up the VM to see if it works, when asked whether you copied or moved it, just answer that you copied it. (I'm not sure what this means, but I think it has to do at least with the MAC address of the vNIC being changed.) enter image description here
  3. If the VM boots up fine, you can remove the VM from the old datastore.
  • rm -rf "/vmfs/volumes/source_datastore/Some VM"

Note: Only tested with ESXi 5

Illustrations shamelessly copied from this blog.

ohaal
  • 2,202
  • 1
  • 19
  • 21
  • 1
    This should work, but even providing info on how to move a VM with snapshots is silly. Tell people to remove all snapshots before attempting a move like this. – pauska Jul 26 '13 at 12:37
  • 2
    @ohaal's post above, in esxi 5.5 u1, had to change the -print0 to -print and it worked like a charm! PS. I'd up vote it but no rep. – icereval Apr 01 '14 at 02:48
  • 2
    @ohaal verified to work on ESXi 6.7. Thank you! – Ed of the Mountain Aug 28 '18 at 15:48
  • 1
    Is there a reason to copy over any other files aside from the .vmdk and the .vmx? If there isn't you can turn the `find` line to a simple `cp`. – Agustín Lado Aug 05 '19 at 16:38
21

You can also use File -> Export -> Export OVF template

and then import it. Last time I tried it, i think this does preserve the vmdk format. Not so sure now as it has been quite some time.

johnshen64
  • 5,747
  • 23
  • 17
  • 3
    Assuming version 4.1 or newer, you'll be prompted to use thin or thick when it is imported. – Jed Daniels Mar 22 '12 at 19:59
  • 2
    You got it! The OVF export to a compresse sparse file was quick and painless. I was given an option to thin or thick provision upon import, and the import was speedy; 5 minutes for a 72GB (8GB used) virtual machine. – ewwhite Mar 22 '12 at 20:03
  • 3
    FWIW, you can also do this from a command line using ovftool. – Jed Daniels Mar 22 '12 at 22:14
8

Check out this answer. The same logic applies in your situation, namely this quotation:

It's called "Converter" but it should really be called "All-Purpose OS Data Mover." Doesn't roll off the tongue quite as nicely, though.

The only difference is that the source and destination hosts will be the same, but the datastores will differ. This does mean that the files will go from the ESXi host, to the Converter machine, then back to the host. It would be nice if Converter was "smart" and knew it was the same host. Unfortunately, that costs money.

CAVEAT: Converting the VM will generate a new MAC address for any network adapters. Most guest OSes interpret this as a new device.

Joel E Salas
  • 5,562
  • 15
  • 25
2

Actually just create the folder at the target destination, then copy the files in the folder from the source and it will stay thin. If you copy the folder it will convert from thin to thick..

Vidar
  • 29
  • 1
  • 2
    This is incorrect. verified using `du -h .` Thin became thick when copied to an already created folder on the same datastore. `cp C* ../newdir` – Rowan Hawkins Aug 31 '17 at 17:47
-1

I would copy the file then reconvert to thin via vmkfstools.

Jim B
  • 23,938
  • 4
  • 35
  • 58
  • The destination datastore size is actually smaller than the source. I haven't enough room to copy the thick file. – ewwhite Mar 22 '12 at 19:14
  • In that case copy and reconvert will not work, but you can also use vmkfstools to clone it directly into the destination. This will also reduce the time needed to transfer it, as it does not transfer the extra GBs of zeroes. My answer contains details on how to do it. – ohaal Feb 23 '13 at 02:41