The physical-to-virtual (P2V) migration process is the first step toward server consolidation, one of the most...
important benefits of virtualization.
The process of converting a physical server into a virtual machine (VM) is a crucial component of any server consolidation strategy. Once you master P2V migration, you can begin consolidating VMs onto fewer physical servers in your virtual infrastructure.
When it comes to a server consolidation strategy, each virtualization platform has its own nuances. But the basic approach is the same, so next I’ll provide a sound server consolidation strategy that works with most platforms -- starting with P2V conversion.
Creating a virtual machine
Before you attempt a P2V migration, you should know how to create a VM. Regardless of which virtualization platform you use, the process is simple. The most important thing to keep in mind is that your host server has limited hardware resources, which must be shared among all VMs residing on a host.
When you create a VM, you must assign resource quantities to the VM. Resource allocation is something of an art form. On one hand, you have to distribute resources sparingly so you don't deprive the host of hardware resources. On the other, you have to give each VM enough resources to function efficiently.
Before you try a P2V migration, it’s a good idea to test the process. You can use this testing phase as an opportunity to experiment with resource allocation.
Testing and performing a P2V migration
There are several ways to perform a P2V migration. Some virtualization platforms have built-in conversion tools. If your platform’s mechanism yields mixed results, though, you can perform a P2V conversion manually. Manual P2V migration usually has a better success rate, and it will work regardless of the platform you use.
The trick to performing a manual P2V migration is to use backup software that supports bare-metal backups and restores to different hardware. To begin the P2V conversion, make a full server backup. Then, create a new VM in an isolated lab environment and restore your backup to that VM. This approach allows the physical machine to remain in use while you test the P2V migration process, eliminating much of the risk.
Once the backup is restored to the VM, you can test it to make sure the virtualized server functions properly. But first, you’ll likely have to install some support services. If you’re using Microsoft Hyper-V, for instance, you have to install Integration Services, which provide Windows with the device drivers it needs to function in a virtual infrastructure.
Temporarily you may have to virtualize other servers as well. Suppose you want to virtualize an application server that depends on Active Directory. If you simply virtualize the server in an isolated environment, you can’t properly test it, because there are no domain controllers in that test environment.
In this case, for P2V migration testing, you need to virtualize one of your domain controllers as well. Note that once you move a virtualized server to a production environment, you no longer need the virtualized domain controller, because a virtual server can now access the necessary domain controllers. (Of course, you can go ahead and virtualize your domain controllers if you want to.)
Once you’re confident that the server works well in a virtual infrastructure, the next step is to move it to a production environment. One option is to create a VM directly within the production environment, then restore a full backup of the original physical server to the newly created virtual server. Or if nothing has changed on a physical server since you began P2V migration testing, you can just export the VM using your virtualization platform’s export function.
Regardless of which P2V migration method you use, bring the physical server that you’ve virtualized offline before you bring the new virtual server online.
The process of performing a P2V conversion isn't complicated. But testing the conversion in an isolated lab environment is critical for your server consolidation strategy. I also recommend starting by virtualizing servers that run simple configurations without numerous external dependencies and avoiding mission-critical servers until you’re accustomed to the P2V migration process.