Over the last few years, I have done hundreds of legacy infrastructure migrations. The hardest-learnt lesson is...
this: Before even touching the technology, get the server or VM owner on board. If you are going from a very old vSphere 3.5 -- or older -- installation to a newer 5.x installation, the offer of better speeds, responsiveness and added room for future vertical growth without added costs should be enough to get the administrators on your side. Usually, with these promises, they are happy to proceed. Keeping them in the loop is critical, especially when downtime is required, as is the case with virtual-to-virtual migrations.
Use secure copy for more command
Migrating guests from a vSphere 3.5 infrastructure to vSphere 5.x is straightforward, but you need to be aware of the pitfalls. Migrating VMs using VMware Converter is easy enough, but I prefer to transfer a guest using secure copy. This allows me to control the process a little better, and I find it easier than dealing with some of the more obscure and cryptic errors you can get with VMware Converter. It is also useful if you do not have admin rights on the guest -- assuming no IP or Domain Name System, or DNS, changes are needed in the virtual guest.
ESXi comes withSSH built in, so, as long as the firewalls allow port 22 TCP, you can copy from A to B without a problem. Machines running VMware Tools version 4 and older are no longer supported in ESXi 5. Don't worry -- we can upgrade it!
Prior to starting the secure copy, don't forget to enable SSH on the source and destination server, and edit or open the firewall as needed. SSH into your source server using the following command or using PuTTY or your favorite secure shell client:
ssh <non root user>@sourcehost
This command is required to be used with a non-root user and then use su – root to get root-level access. This is by design on older versions of ESX when the console port was based on RedHat and featured standard Linux security features. If you do not have a non-root user, log in using the vSphere client and create one.
As any self-respecting VMware engineer should know, your VMs will be located in the /vmfs/volumes directory on the server. Create an empty folder on the destination server with the same name, and then copy using the following syntax:
scp –r /vmfs/volumes/mymachine/* root@destinationhost:/vmfs/volumes/mymachine
This will copy the files that make up the VM, one by one. Before you run the command, be sure you are copying from the source to the destination. If you are having issues with the copy, you can use the scp switch -vv, which will give very verbose output to assist with troubleshooting.
Once the copy is complete, you can add the VM into the current infrastructure manually. Do this by browsing to the destination folder of the machine you just migrated, using the Datastore view in the vSphere client and locate the VMX file that is associated with the newly migrated VM. Right-click on it and a wizard will walk you through where the VM is to sit and other required information.
If you power the machine up, VMware Tools will report an error about running a VM with hardware version 4 or below, and will show VMware Tools as "Not running -- Unsupported." Fortunately, the fix of upgrading the hardware for the machine is easy enough.
Upgrade VMware Tools the proper way
To upgrade the machine, run VMware Tools update; on the guest console, select VM, then Guest and then Install/upgrade tools. I chose Automated and let it do the upgrade. If you don't have admin rights, this is the only way to upgrade. From here, upgrading the virtual hardware is simple. Ensure the newly added guest is turned off, then right-click the guest menu and select Upgrade hardware, which will upgrade the hardware to the latest supported version. After the machine is power-cycled, you will now be in possession of a migrated VM running a supported version of VMware Tools.
Test following the conversion
You should also do some functional tests to ensure everything works properly. Can the VM be contacted via ping? Are the applications running as expected? As an extra measure, turn the VM over to the business owner for sanity tests and further assurance that everything is performing as expected.
Minimize downtime with tools
Sometimes a VM can't really afford to have a lot of downtime. There are a couple of ways to handle this. The cheapest way is to use VMware Converter, which has features that allow the VM you are using to stay up during the copy; at the end of the copy, it will synchronize the VM and shut down the old version.
A more advanced version of this functionality is available in tools provided by companies such as PlateSpin. These migration utilities make the initial copy without downtime and keep VMs synchronized while the server is up. It allows the administrator to manually choose a cut-over point, and will instantly do the final steps of the migration and power down the old host and power up the new one with minimal downtime.