Hyper-V Physical to Virtual

There are many different options for converting a physical server into a virtual machine (VM). Some backup applications, for instance, include an option for performing physical to virtual (P2V) conversions. Likewise, there are standalone utilities that can assist with the P2V conversion process.

In most cases, copying the contents of a physical server into a VM is straightforward. However, there are a number of issues that must be taken into account prior to performing a physical to virtual migration.

Legacy OSs and the P2V conversion

The first issue to consider is the operating system (OS) running on the system that is to be virtualized. Ideally, your hypervisor vendor should support the OS for use in its VMs. In the case of legacy workloads, however, formal support may not exist. For example, there are production systems that still run on Windows 2000—this OS is now so old that neither Microsoft nor the hypervisor vendors support it.

This doesn’t mean you can’t virtualize the server. Just about any OS can theoretically operate within a virtual machine, regardless of whether or not it is officially supported. I have personally created VMs that run DOS and even Windows NT. You do need to be aware that even though these operating systems can run in a VM, they can cause problems. For example, an old or obscure OS probably isn’t going to work with Hyper-V Integration Services or VMware Tools. This means it may be a challenge to get the OS to properly recognize some virtual hardware components, such as virtual network adapters. It is also possible that your backup software may have trouble protecting VMs running outdated operating systems.

Creating the right hardware environment

Another challenge with migrating a legacy physical server to a virtual environment is Hardware Abstraction Layer (HAL) support. Suppose for a moment that you have a really old server running an outdated operating system. This operating system’s installation process deployed the OS in a way that would allow it to run on the server’s CPU.

With that in mind, imagine that you back up the server, and then restore the backup to a VM. Depending on the age of the legacy server’s hardware, there is a good chance the OS will not run on the VM, because the virtual hardware is too different from the hardware that the OS was previously running on. You may end up having to manually install the OS onto the virtual hardware in order to make the OS function properly. You may be able to get away with configuring the VM to use processor compatibility mode, but doing so prevents the VM from taking full advantage of the host server’s CPU capabilities.

Other considerations for P2V conversions

Prior to performing a P2V conversion, it is also important to consider whether the hypervisor can adequately match the physical host’s hardware configuration. It is usually easy to create a VM that has the correct number of virtual hard disks and network adapters, but some physical machines contain hardware that can be difficult or impossible to re-create in a virtual environment. For example, the server may depend on a legacy serial device or perhaps a physical GPU.

It isn’t enough for the hypervisor to be able to create virtual representations of the hardware that is being used by a physical server. The server’s OS must be able to detect and use the virtual hardware. This can be a major problem for an aging OS due to the unavailability of device drivers. In some cases however, a hypervisor may be able to emulate some of the more common legacy hardware components.

Testing your P2V conversion process

When it comes to performing a P2V conversion, it is extremely important to test the conversion process in a lab environment prior to attempting it in production. No two P2V conversions are the same, and there is a lot of room for things to go wrong along the way. Lab testing will give you the chance to spot and work through problems before you make any changes to your production environment.

Brien Posey is a 13 time Microsoft MVP with over two decades of IT experience. Prior to going freelance, Posey was a CIO for a national chain of hospitals and healthcare facilities and has served as a network engineer for the United States Department of Defense at Fort Knox. Posey has also worked as a network administrator for some of the largest insurance companies in America.

You can follow Brien on Twitter at @BrienPosey