Get started Bring yourself up to speed with our introductory content.

A how-to guide to migrate off legacy infrastructure

For VMware administrators, both physical and virtual machines become outdated and need to be updated to gain efficiency and reduce the support costs associated with legacy software and hardware.

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.

This was last published in December 2014

Dig Deeper on Creating and upgrading VMware servers and VMs

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What are some effective tools and strategies for migrating off legacy infrastructure in a VMware environment?
If I am looking to migrate to VMware environments from off legacy infrastructure, I rely on VMware Converter or possibly use a secure copy just in case I need more control on processes. Though migrating using VMware Converter is more easier, using a secure copy like ESXi with a built-in SSH provides me the opportunity to be in control of the processes. But with VMware Converter, I risk encountering cryptic errors during the migration process.