There are countless tools available for performing physical to virtual conversions. Although many of these tools come with a premium price tag, at least one of the tools is available for free – Microsoft’s Disk2VHD. Disk2VHD is one of the Windows Sysinternals tools, and you can download here.
Disk2VHD is an amazingly lightweight tool. In fact, the download is less than 1Mb in size. Furthermore, the tool’s interface couldn’t be simpler. Just select the volumes that you want to convert, verify the path name, and click Create. You can see what the interface looks like in the screen capture below (there is also a command line interface):
This is the Disk2VHD interface.
Given this tool’s simplicity, it might at first seem as though there isn’t much to say about the physical to virtual conversion process. However, the simplicity of the interface is somewhat deceptive. Although I have used Disk2VHD to successfully perform physical to virtual conversions, I have also had plenty of unsuccessful conversions. Over time I have learned that there are some things that can cause the conversion process to go badly. In this article, I want to share with you some of the best practices for using the Disk2VHD tool.
The first best practice that I want to mention is to make sure that you have the most recent version of the tool. Like all of the Sysinternals tools, Disk2VHD is sometimes updated. The current version is 2.01, and the tool has not been updated since 2014, but you never know when a new update might be released.
Another important thing to know about Disk2VHD is that you must be careful with how you handle the resulting virtual hard disk file. As I’m sure you probably know, the last few versions of Windows have allowed you to mount a virtual hard disk by double clicking on it. By doing so, you can access the virtual hard disk’s contents.
On the surface, this sounds like a handy capability. After all, you could theoretically create a virtual hard disk, open it, add some driver files to the virtual hard disk, and then dismount the virtual hard disk and link it to the virtual machine. In fact, I have attempted this technique myself. Generally speaking, the technique works well, but there is one big gotcha.
When you perform a physical to virtual conversion, Disk2VHD does not destroy the physical server’s contents as a part of the conversion process. When the conversion completes, the virtual disk mimics the physical disk, but the physical disk remains intact, and the physical machine remains fully functional. Herein lies the problem.
The Windows operating system writes a signature to each disk. This signature is used as a mechanism to allow Windows to identify the disk. Because the virtual disk is an exact copy of the physical disk, it contains the same signature as the physical disk from which it was created. As such, if you were to mount the virtual disk using the same physical machine that the virtual disk was created from, a signature conflict will occur. Windows will attempt to resolve the conflict by writing a new signature to the virtual disk. In doing so, Windows renders the virtual hard disk unbootable. If you were to later attach the virtual disk to a virtual machine, the virtual machine would not be able to boot because the disk’s Boot Configuration Database references a disk signature that no longer exists.
Another important thing to know about the Disk2VHD utility is that you have to be careful about using it on a system that is running. The Disk2VHD utility works similarly to the way that a backup application works. When you run the utility, it uses the Volume Shadow Copy Service (VSS) to create a snapshot of the disk that is being converted. This allows the disk to be converted without fear that its contents will be modified during the conversion process. Doing so helps to ensure the integrity of the resulting virtual hard disk, but the flip side to that is that any data that is created or modified on the physical server during or after the conversion process will not be included in the virtual hard disk. This means that there is a potential for data loss, especially on systems that run highly transactional applications.
There are a few different ways to get around this particular problem. The best option for highly transactional application servers that must remain online is probably to use data replication to assist with the virtualization process rather than relying on Disk2VHD. Consider Exchange Server for example. While it is theoretically possible use Disk2VHD to perform a physical to virtual conversion of an Exchange Server, there is a very real risk of data loss because messages will continue to be sent and received after the conversion process begins.
A better solution might be to manually deploy Exchange Server onto a virtual machine. After doing so, the virtual machine could be added to a database availability group, and a database copy (from the physical server) could be added to the virtual machine. Once everything has had time to sync, the database copy could be removed from the physical server, thereby leaving the virtual machine to host the Exchange Server database. At that point, the physical Exchange Server could be removed from the Database Availability Group, so long as enough servers remain for the database availability group to retain quorum. Once the removal is complete, Exchange could be manually uninstalled from the server.
If on the other hand, an organization needs to perform a physical to virtual conversion on an Exchange Server, an SQL Server, or some other type of highly transactional application server, but lacks the resources to use the previously described method, there is a way to help the Disk2VHD utility to complete the conversion without data loss.
To do so, schedule some down time, and then stop and disable any system services that are related to the application. Doing so will prevent the application from being active during the conversion process, and should prevent data loss from occurring.
Conclusion
As you can see, the Disk2VHD utility makes it easy to copy the contents of a physical hard disk to a virtual disk. You can then create a Hyper-V virtual machine, attach the virtual hard disk, and start a virtualized copy of the server.
One thing to keep in mind, is that you will likely have to make a few adjustments to the virtual machine prior to placing it into production. At the very least, you will probably need to install the Hyper-V integration services, but you might also need to make some alterations to the network configuration. This is because a physical server using a physical NIC will lose its IP address configuration as a part of the virtualization process, because the virtual NIC has a different name than the physical NIC. As such, it is important to document the server’s IP address configuration prior to virtualizing the server, so that you can assign those settings to the server’s virtual NIC.
