The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,781 other followers

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.

  1. 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).
  2. Note the “startup order” of your VMs
  3. Note the full datastore path GUID(s) of your source ESX machine
    (GUID = number formatted like “########-########-####-############”)
  4. Note the full datastore path  GUID(s) of your target ESXi machine
  5. 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)
  6. 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)
  7. Create the same pools (high, low, etc) on your target as your source
  8. Shutdown all your VMs
  9. (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).
  10. 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)
  11. Copy all your .vmx files to a place where you can edit them
  12. In each .VMX file, perform these actions:
    1. Remove all lines containing ‘sched.swap.derivedName’ (if needed, ESXi 4.1 will regenerate those values)
    2. Replace the datastore path GUID numbers of your source by the equivalent in your target
    3. Copy the .VMX file over the one in your target (using Veeam or the data store browser).
  13. Check for each VM if the connected networks are working OK (they should be the same as your original ESX box)
  14. Test all the VMs
    For each VM, mark it as “I have moved it”  when a
  15. If everything works OK, fix the “startup order” of the VMs
  16. Perform a test reboot of your ESXi server

Notes:

  1. Replacing the GUID(s) for me resulted in replacing this:
    /vmfs/volumes/48e5fa96-2aff1e07-3623-001517777c91/
    

    with this:

  2. /vmfs/volumes/4c595d79-4bba1b16-c2d7-001f29011276/"
    
  3. 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$"`
  4. 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.

  5. /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

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

 
%d bloggers like this: