Every virtual server migration requires a plan and process, as well as server migration tools. The basic process follows four fairly straight-forward steps:
- Create a virtual machine (VM) with sufficient disk space to hold the contents of the physical server.
- Copy the data and operating system (OS) from a physical server to a VM.
- Fix up the resulting guest OS to see the virtual hardware presented.
- Reboot the VM.
While these four steps seem to encompass quite a bit of black magic, the reality is that the virtual server migration process itself is fairly logical. That said, the migration is not a trivial matter but one that should be monitored very carefully.
The answers to the frequently asked questions below will help safeguard your virtual server migration plan.
Can the virtual server migration be performed without rebooting the physical server?
This depends on the OS in use. For some versions of Windows, server migration tools allow you to perform the server migration without rebooting the physical server. However, other operating systems require a reboot.
To test whether this applies to your migration, pick an unused server. If one does not exist, create one. Next, deploy your server migration tool of choice. You may find that one tool works better than another. For older operating systems, a reboot is almost always required, as you need to use a boot disk to perform the migration.
What virtual server migration tools are available?
There are several tools that can be used. Each of the hypervisor vendors has their own tools, and there are also third party tools available, such as Platespin, Leostream and vConverter. In addition, many free tools are available. For example, you could restore from backup into a virtual machine with Symantec Ghost or other such disk copy tools.
What information do I need to develop a virtual server migration plan?
It is important to create a capacity plan that encompasses CPU, disk, network, and memory resources. You need this information to determine whether or not a physical server is a good candidate to migrate or if the physical server will require special configurations within the virtualization host. A capacity plan will also determine if you need to purchase more virtualization host licenses, hardware, etc.
This is one step that is often overlooked. Capacity plans require looking at data over several months to determine the exact state of the physical host. From that data, a server migration guide or plan can be developed. All the hypervisor vendors have such capacity planning tools. Do not skip this step.
What are some virtual server migration tips that will help me avoid problems?
There are several issues that could cause a server migration to fail:
- Ports not opened on firewall(s) to allow the server migration tool to work.
In general, each product requires certain firewall ports to be opened. Pay close attention to the documentation. Some of these ports will never be opened by your network and security administrators. In this case, you should make the target of your server migration a USB or eSATA disk that can be moved from one security zone to another.
- Not enough disk space to store resultant virtual disk files.
When you copy the contents of a physical machine, you have the ability to resize the resultant virtual disk to encompass all the used space within the physical server. In general, a virtual disk should be smaller than the physical disk, but this depends on the application more than anything.
- Resultant VM cannot find boot disk.
This implies that the "fix up" step of the server migration process failed. Either redo the server migration or do the "fix up" by hand. In general, this happens when migrating from IDE physical disks to SCSI virtual disks. The proper drivers were not loaded into the OS.
- Resultant VM boots then crashes.
In many cases, this implies that the guest operating system has a driver issue. One such fault in Windows, for example, is an out of data lsass.exe file.