Migration marks the start of a path toward virtualization and a great deal rides on its success, but the looming question remains: "How do I get there?" A failed virtual machine server migration can cause an organization's key decision makers to doubt the maturity of virtualization technologies and possibly pull the plug on the project, so it's important to answer that question correctly.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Organizations have had to work through problems with physical-to-physical migrations for years. There is often little difference between migrating a physical system to a virtual machine and migrating one physical server to another newly purchased physical server. However, most organizations see new physical systems as known commodities that will meet expectations once initial migration glitches are resolved. Server virtualization to many
shops remains an unknown; it's always easiest to blame the virtualization technology when a migration problem arises, than accept it as a typical issue involved with migrating a system's software to another with dissimilar hardware. Ultimately, all physical-to-virtual (P2V) migration projects are loaded with pressure. Failure could easily set an organization's virtualization motives back six to 12 months. If you're a VAR or independent consultant, this failure can equate to a significant amount of lost revenue.
So what do you do? The key to successful migration is to carefully evaluate the available conversion methods and align the right conversion process with each organization's requirements. Today there are three general approaches to migrating physical servers to virtual machines:
- Using a third-party P2V tool.
- Using the virtualization platform's available tools.
- Manual via cloning or backup and recovery.
The simplest method for VM conversion is to use a third-party conversion tool. Since these tools were developed with the sole purpose of physical-to-virtual system conversion, they are far and away the most reliable and efficient. Available tools in this space include:
I always recommend using enterprise P2V conversion tools, but if the project is too small, an alternative is to use the tools provided by the virtualization platform vendor. Some vendors bundle third-party P2V tools with their product licensing. Virtual Iron, for example, provides a single PlateSpin PowerConvert conversion license with each Virtual Iron Enterprise Edition license. VMware automates conversion using its VMware Converter tool, which is currently in beta. Microsoft's approach involves the use of Automated Deployment Services (ADS) and is documented in the Virtual Server Migration Toolkit (VSMT). Due to the complexity of the documented VSMT migration, many IT pros have shied away from this method in favor of either a third-party tool or manual conversion.
Manual conversion involves two general approaches: cloning via third-party imaging software or manually restoring data to a staged virtual machine from backup. Several third-party imaging tools have added support for restoring images to VHD and VMDK virtual hard disks. This allows them to be used to clone a physical system and restore the cloned image to a new virtual machine. Two products that support imaging and deployment to virtual machines are Symantec Backup Exec System Recovery and Acronis True Image. Ideally, you should work with imaging tools that support bare-metal restores to ensure the image can be restored to alternate hardware, such as a virtual machine's emulated hardware.
One other option would be to manually install the source system's OS into a new VM, then use your backup software to migrate the production server's data to the VM. Alternatively, if the production server has a dedicated data disk, you can bind the physical disk directly to the VM. This will allow you to directly connect the existing source server data disk resources to the new VM. If you do consider logging into the VM and copying the data on the disks to a new virtual disk connected to the VM. This will ensure data portability (no dependence on a physical disk) and give you more flexibility with VM deployments.
There are plenty of ways to go about migration, with commercial P2V tools being the method of choice among most virtualization consultants. Again, the most significant part of any physical to virtual migration is that the system conversion works. Failure to successfully migrate physical resources can quickly result in lost confidence in virtualization and possible project termination. Bottom line: If you have no confidence in a tool or approach, don't use it.
About the author: Chris Wolf is a Microsoft MVP for Windows Server -- File System/Storage and is a MCSE, MCT and CCNA. He's a senior analyst for Burton Group who specializes in the areas of virtualization solutions, high availability, enterprise storage and network infrastructure management. Chris is the author of Virtualization: From the Desktop to the Enterprise (Apress), Troubleshooting Microsoft Technologies (Addison Wesley), and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press). Reach him at firstname.lastname@example.org.