As virtualization has become the norm, the need for physical-to-virtual conversions (P2V) has begun to decline for many of us. There are still a great number of legacy systems waiting their turn to be transferred. There are also many administrators inheriting systems from exiting staff that avoided virtualization right up to the bitter end. Whatever your situation, this article is for you.
What is a Physical-to-Virtual Conversion?
In simple terms, a physical-to-virtual (P2V) conversion transfers the entire state of an operating system installed on bare metal into a virtual machine. It is commonly done with the intent of retiring old hardware without rebuilding the system. It is also commonly done when an organization first begins to transition from an all-physical environment to a virtual environment.
Good Advice: Do Not Perform P2V Conversions
Truthfully, the best approach is to not perform P2V at all. It is fraught with peril. You will probably spend hours making your converted system work correctly. You will have a hybridized system that may not ever function optimally. Software support departments won’t like it. You might never make the thing work at all.
In particular, do not perform P2V for these systems:
- Domain controllers
- Exchange servers
- Systems that rely on specialized hardware, such as fax boards and licensing dongles
Migrating Active Directory Domain Servers is preferred to a P2V operation just because moving domain services is ridiculously simple:
- Build a new Windows Server operating system environment
- Promote the new system to be a domain controller. For some reason, the TechNet article that describes how to promote a new domain controller makes this process look extremely difficult, but it isn’t. Even the article’s title includes the text “Level 100”.
- Install DHCP, if necessary. Use a DHCP failover scope to transition DHCP services from old to new.
- Demote the old domain controller.
- Remove the old domain controller from Active Directory Sites and Services.
- Decommission the old domain controller.
If you want to continue using the same IP address and name of the original domain controller, then perform the migration twice, with the second migration using the original name and IP.
Converting Exchange is more or less the same operation: add the new server into the Exchange infrastructure and remove the old one.
I am tempted to include Internet Information Services (IIS) in the list of “never migrate” just because moving IIS is usually very simple as well, but many of my earliest P2V experiences were with IIS and those ended well. I would not P2V SQL, though.
Whatever your application is, start with your favorite Internet search engine or the application’s support team and research migrating from one server to another. Wherever possible, always choose a data migration path over a physical-to-virtual conversion.
Problems with P2V Conversions
These are the things that you can expect to have trouble with after a P2V:
- Hard drives: Windows has never transitioned well from RAID to non-RAID environments. Versions prior to 2008 commonly failed when transitioning from SCSI to IDE or vice versa. Often, after a P2V, you will encounter 0x0000007b stop errors, which essentially mean that the boot loader could not find the startup files. Unfortunately, these errors are commonly insurmountable, although you might be able to use the Windows repair options from the installation media.
- Phantom drivers: Completely removing old driver packs and supporting software might prove to be difficult. Windows will hide drivers for which it can’t find matching hardware. Some manufacturer removal routines are less than thorough. Do not be surprised if you encounter IRQL_NOT_LESS_OR_EQUAL errors after a P2V; these are hardware-related. MSDN has an article explaining how to view and remove devices that are no longer present (make certain that you perform the steps regarding the DEVMGR_SHOW_NONPRESENT_DEVICES environment variable.
- Activation: All software, including Windows, that tracks licensing by hardware signatures will be triggered by P2V. It is against the license agreement to move an OEM copy of Windows. Other software may have similar restrictions. Not all will prevent the migration, which means that you could unknowingly be in a sticky legal situation after a successful P2V.
- Support: many vendors will not support their software if it has been moved by P2V. I don’t like the software vendors that look for excuses any more than you do, but there’s no denying that you can’t always be certain that an issue wasn’t caused by P2V.
- Operating system issues: as fate would have it, newer operating systems that are less likely to need to be P2Ved are more likely to survive a P2V. The older operating systems that you might need to P2V just so you can limp along to a software replacement/upgrade are more likely to fail. Windows Server 2003 had some special troubles in migration. I have an article on my own blog that talked about some issues that I found for Windows Server 2003 P2V.
Increasing the Odds of a Successful P2V Conversion
Sometimes, P2V is just what needs to be done. There are a couple of things that you can do to increase the odds that your conversion will be successful:
- Backup! Do not even attempt a P2V unless you have a solid backup!
- Replace OEM operating systems with fully-licensed versions. For 2003, all you had to do was use the fully-licensed media and upgrade the existing installation, using the proper key. Of course, that’s risky, and is best done prior to the migration.
- Remove all drivers that are not essential for the move. Also remove any monitoring and maintenance software that is particular to the system’s hardware.
- Pre-install Hyper-V Integration Services. In the C:\Windows folder of your target Hyper-V host, you’ll find a vmguest sub-folder with all of the necessary files. If you prefer, there is a vmguest.iso in C:\Windows\system32 .
Tools to Perform a P2V Conversion
There are a number of options for performing a P2V. These are the most common methods:
- Microsoft Virtual Machine Converter (MSVMC) version 3.0 (or later). This is the preferred method, as it will perform a true conversion (stay tuned for an article about MSVMC on Thursday 25th) .
- Disk2VHD is provided by Sysinternals, which is now part of Microsoft. This tool converts a live hard disk to a VHDX. It is not truly a P2V operation as the operating environment is completely unmodified, but the resulting VHDX can be attached to a new virtual machine.
- Disk clone utilities such as Clonezilla . I wrote an article aboutusing Clonezillathat was intended for V2P, but truthfully it could be used for just about any migration type.
- Standard backup and restore software likeAltaro VM Backup . You could back up the physical environment using traditional software, build a new virtual machine with an empty copy of the operating system, and restore from backup.