Moving my VMs from ESX 3.5 to ESXi 4.1
Posted by jpluimers on 2010/09/23
After doing quite a bit of research and testing, these are the steps I used to move my VMs from an ESX 3.5 box to an ESXi 4.1 box.
- Have a test scenario for all your VMs so you can prove they work.
(for instance, when using an Endian Firewall appliance VM (their community edition is free), your scenario could include that people can remotely connect as they did before, and the proxy server still works). - Note the “startup order” of your VMs
- Note the full datastore path GUID(s) of your source ESX machine
(GUID = number formatted like “########-########-####-############”) - Note the full datastore path GUID(s) of your target ESXi machine
- License your target machine
(on second thought: you might want to do all of this in your 60-day evaluation period, as the evaluation license can do more than some of the other licenses) - Create the same network config (virtual switches, etc) on your target box as your source box (make sure you name them exactly the same way)
- Create the same pools (high, low, etc) on your target as your source
- Shutdown all your VMs
- (you might get by this and suspend your VMs in stead of shutting them down, but this is a high risk, and will only work if the target hardware and source hardware matches).
- Transfer all your datastore files from your source to your target, and keep the data structure.
(having a gigabit connection between source and target is a real benefit here;
observed speeds:
– gigabit: 30 – 50 megabyte/s – limit is HDD speed
– 100mbit: 5-13 megabyte/s – limit is LAN speed)
(Use Veeam Backup and FastSCP 3.0.3 or better, or Veeam Backup and Replication 4.1.2 or better to do the transfer) - Copy all your .vmx files to a place where you can edit them
- In each .VMX file, perform these actions:
- Remove all lines containing ‘sched.swap.derivedName’ (if needed, ESXi 4.1 will regenerate those values)
- Replace the datastore path GUID numbers of your source by the equivalent in your target
- Copy the .VMX file over the one in your target (using Veeam or the data store browser).
- Check for each VM if the connected networks are working OK (they should be the same as your original ESX box)
- Test all the VMs
For each VM, mark it as “I have moved it” when a - If everything works OK, fix the “startup order” of the VMs
- Perform a test reboot of your ESXi server
Notes:
- Replacing the GUID(s) for me resulted in replacing this:
/vmfs/volumes/48e5fa96-2aff1e07-3623-001517777c91/
with this:
- If none of your .vmx files contain spaces, you can find the ones containing “sched.swap.derivedName” using this command-line on your ESXi console (or ssh connection):
grep -l "sched.swap.derivedName" `find /vmfs/volumes | grep "vmx$"`
- To find the GUID of your datastore(s), perform this command:
ls -ld `find /vmfs/volumes | grep datastore`
which will reveal entries like this:
lrwxr-xr-x 1 root root 35 Aug 10 09:24 /vmfs/volumes/datastore1 -> 4c595d79-4bba1b16-c2d7-001f29011276
As an alternative, you can use
ls -l /vmfs/volumes/
Then look for directories with:
- names formatted like “########-########-####-############”
- that datastores named like “datastore#” points to,
- with dates other than “Jan 1 1970”
like the “4c595d79-4bba1b16-c2d7-001f29011276” sample from the directory listing below.
/vmfs/volumes/4c595d79-4bba1b16-c2d7-001f29011276/"
/vmfs # ls -l /vmfs/volumes/ drwxr-xr-x 1 root root 8 Jan 1 1970 3c3693e8-f77a642a-1910-5c6bdcb26d3a drwxr-xr-x 1 root root 8 Jan 1 1970 4c595d77-759e73a4-1c06-001f29011276 drwxr-xr-t 1 root root 1960 Aug 6 21:10 4c595d79-4bba1b16-c2d7-001f29011276 lrwxr-xr-x 1 root root 35 Aug 10 08:47 Hypervisor1 -> b7322b70-626659ce-c9cb-256d7ec6a809 lrwxr-xr-x 1 root root 35 Aug 10 08:47 Hypervisor2 -> d01e7671-215df396-e8f8-e0f990b59662 lrwxr-xr-x 1 root root 35 Aug 10 08:47 Hypervisor3 -> 3c3693e8-f77a642a-1910-5c6bdcb26d3a drwxr-xr-x 1 root root 8 Jan 1 1970 b7322b70-626659ce-c9cb-256d7ec6a809 drwxr-xr-x 1 root root 8 Jan 1 1970 d01e7671-215df396-e8f8-e0f990b59662 lrwxr-xr-x 1 root root 35 Aug 10 08:47 datastore1 -> 4c595d79-4bba1b16-c2d7-001f29011276
–jeroen
Leave a Reply