P2V: Converting a Windows 10 Physical Installation to a Virtual Machine: External Methods

I had Windows 10 installed on my desktop. I wanted to create a virtual machine (VM) from it. For this purpose, prior explorations had inclined me to favor VirtualBox over VMware Player. The process of converting a physical installation to a virtual one was often referred to as simply P2V. I was looking for the best way to achieve that conversion.

The title’s reference to “external methods” alludes to the distinction developed in another post. For purposes of conversions between physical and virtual installations, an internal method is one that achieves the conversion by running software inside the VM, while an external method runs software outside the VM. A different post explores internal solutions that may help to illustrate this distinction.

To keep the size of the host and VM installations small, I applied the space reduction techniques suggested in a prior post. These steps reduced the size of the (uncompressed) Win10 installation from 48GB to 29GB.

This post deals only with the process of producing a working VM from a physical installation. Another post addresses additional issues, including activation, and there is also a post focused on measuring this VM’s performance.

Choosing Among P2V Tools
Making the VMDK Work Properly in VirtualBox
Converting VMDK to VDI and Moving It

.

Choosing and Using P2V Tools

For the P2V operation, sources recommended several tools. AOMEI preferred their own AOMEI Backupper Professional ($40), of course, but also acknowledged the alternatives of Microsoft’s Sysinternals Disk2VHD and System Center Virtual Machine Manager (SCVMM). Like AOMEI, Acronis and perhaps other vendors of drive imaging software offered the possibility of restoring a drive image in an empty VM (though one participant in that Acronis discussion described this approach as “far from reliable”). Other possibilities: StarWind said that their V2V Converter now had a P2V option; Iperius cited VMware’s vCenter Converter; and possibly one could install Win10 in an empty VM from an ISO created through a Windows To Go (WTG) approach.

I found some of those options relatively unappealing. The WTG route seemed roundabout, in a setting where every additional conversion or installation step was another possible point of failure. The SCVMM tool was apparently oriented toward Hyper-V, whereas I was planning to run this VM in VirtualBox. I’d had good recent experience with AOMEI as a drive imaging tool, but I dimly recalled a failed attempt to restore a drive image to a VM, and was thus inclined to agree with the doubt voiced in that Acronis discussion.

It seemed the best approach would be to use a tool intended for P2V conversion. That meant Disk2VHD, StarWind V2V Converter, or VMware’s vCenter Converter. In terms of outputs, it appeared that Disk2VHD produced VHD files only; StarWind seemed to produce VMDK and possibly VHD files; and VMware’s vCenter Converter apparently produced VMDK and possibly other formats. According to Oracle, VirtualBox could handle both VMDK and VHD. Various sources (e.g., SuperUser) suggested that VMDK was used by more virtualization tools (e.g., VMware, VirtualBox) than was Microsoft’s proprietary VHD format. I did not presently intend to use the VM on anything other than VirtualBox, but there was always the possibility that I would want to. In that case, I could run a VMDK on VMware, but would have no direct use for a VHD. A SuperUser answer said that VHD would be best converted to VDI before being used in VirtualBox, because it was more difficult “to periodically compact the VHD to recover space.”

In a brief sampling of informative websites, Disk2VHD appeared to be used more often than the others. The Sysinternals tools, of which Disk2VHD was one, had a long-established reputation. As a past user of VMware Workstation, my brief prior exposure inclined me to believe that the vCenter Converter would also be solid. I was less certain about StarWind; it appeared that they had only recently added their P2V capability. That seemed consistent with the 3.9 stars awarded by 31 users and 3.5 stars awarded by staff at Softpedia. Disk2VHD did better at Softpedia, with 4.1 stars from (only) 14 raters and 4.0 stars from staff. Possibly the average user rating for those two tools would have gone down as other users weighed in. Or for some reason, anyway, VMware vCenter Converter averaged only 3.6 stars from 138 raters, but 4.5 stars from staff, at Softpedia.

Given my own prior experience with VMware, as well as the greater perceived usefulness of the VMDK format, I was inclined to favor VMware’s vCenter Converter. That inclination was consistent with a belief that VMware’s corporate focus on virtualization probably meant more attention to the details. Maybe that explained the difference in footprint, between the 879KB size of Microsoft’s Disk2VHD program and the 171MB size of vCenter Converter.

So I downloaded VMware vCenter Converter and installed it. Installation concluded with an offer to run it. That was a bust: it gave me some gibberish about connecting to a server. I killed it and started over. This time it gave me a more reasonable, general-purpose interface. In the toolbar, I clicked the Convert Machine button. That gave me an option to Select Source Type. I chose This local machine > Next. That resulted in an error: “Permission to perform this operation was denied.” So, OK, I killed vCenter Converter and started over again, this time right-clicking on its Start Menu icon and choosing the Run as administrator option. That got me past the error message. Now the User Guide said … nothing of relevance. After some flailing around in a vain search for guidance, I guessed and chose Destination Type = VMware Workstation or other VMware virtual machine, and VMware Product = the free VMware Workstation Player, of which the current available version was 15.5 (4.3 stars from 432 raters on Softpedia). I did download it, but had to do so in Chrome; the Firefox page hung. From the fact that vCenter Converter anticipated nothing more recent than Player version 12, I guessed that it had been a while since vCenter Converter was last updated. Otherwise, I went with the defaults. vCenter proceeded to create its VMDK file, which wound up being 24GB. It was reasonably fast. I didn’t time it, but it was done in less than 15 minutes.

While I had the computer all prepped for virtualization, I decided I had better give Disk2VHD a go as well, just in case I didn’t like the VMware outcome. Disk2VHD ran as a portable; no installation required. In Disk2VHD, I unchecked the VHDX option, based on indications that VirtualBox was compatible with VHD but not VHDX. By default, all available volumes on the system were checked. I had to uncheck all but the one for drive C. (In light of the fact that this produced a nonworking VM, maybe I should have checked one or more  of the others as well.) I selected a destination drive and folder and clicked Create. It might have been faster than VMware. Its resulting VHD file was 25GB.

Now it was time to try to run VMware’s VMDK and Disk2VHD’s VHD output files in VirtualBox. In VirtualBox Manager (VBM), I used toolbar > New > Expert Mode > Use an existing virtual hard disk file > click the folder icon at right > Add > navigate to where the VMDK and VHD files were stored. It was able to see both, so I added both, one after the other. Then I selected the VHD > Choose. I named this one Win10VHD, and designated the folder where I wanted the Win10VHD folder to be created. I gave it 3000MB RAM > Create. (I would later change that RAM value and other settings.) In VBM, I clicked Start. After a moment, I got FATAL: INT18: BOOT FAILURE. I tried again with the VMDK. That one ended in “FATAL: No bootable medium found! System halted.”

Nakivo provided a troubleshooting page that claimed to go through most of the possible causes of this problem. A VirtualBox forum discussion raised the possibility that at least the Win10VHD problem might be fixed by booting the VM with a Windows system repair or installation disk, and using that to mark the partition in the VM as active, and then let the tool finish repairing the installation.

My reading (in e.g., the VirtualBox forums) suggested that the problem might be that the source computer had UEFI rather than legacy BIOS. Comments of that nature seemed to imply that this would be a drawback of using these relatively old virtualization tools. A SuperUser answer said VBM had an answer: Settings > System > Motherboard tab > check Enable EFI. That helped to at least advance the process a bit with Win10VHD: an UEFI Interactive Shell opened and left me at an inscrutable prompt. (See another post for further discussion of VirtualBox difficulties.)

With the Win10VMDK, the EFI setting did better: the VM ran and, after a minute or two of the Win10 “Getting devices ready” screen, it deposited me at my familiar Win10 login screen. So VMDK with EFI enabled was the solution so far. The inferior result with VHD was consistent with one or two negative remarks about VHD that I saw somewhere in the VB forums, as I continued reading.

To review, this section describes my selection process. I wound up trying VMware vCenter Converter and Microsoft’s Disk2VHD. The former gave me a VMDK file that, after selecting the VirtualBox EFI option, did produce a working Windows 10 VM that virtualized my native desktop installation. The latter gave me a VHD file that might have been made usable with additional effort — though prior experience suggested it might not. If I’d been forced to work with the VHD file, my next step would have been to try converting it to VDI (below). If neither the VMDK nor the VHD files had worked, I would then have tried using KYHI’s version of AOMEI Backupper, or perhaps Acronis or some other drive imaging tool, to create an image of the native installation; then I would have attached a bootable ISO of that same tool to an empty Win10 VM and tried restoring the image there. Alternately, presumably I could have run the VMDK in VMware Player instead of VirtualBox, or the VHD in Hyper-V.

Making the VMDK Work Properly in VirtualBox

Now it was time to fix performance and display issues in the Win10VMDK VM. I started by going into Win-I > Display > Resolution. It was locked at 1024 x 768. I went to the VirtualBox menu along the top of the VM (i.e., not the VBM menu) > Devices > Insert Guest Additions CD Image. That didn’t yield any other resolution options, even after a reboot. To try to improve performance, in VBM > Settings I went to System > Processor tab > bump it up to 2 CPUs. In Display > Screen tab, I gave it 256MB virtual memory and enabled 2D and 3D acceleration. Those changes didn’t seem to help, when I booted the VM. I thought there might be a driver issue, so I went into the VM’s Win-I > Update & Security > Windows Update. But it said I was up to date. There was nonetheless a notification (in the bottom right corner of the Windows 10 screen) that said this:

Searching for Display Driver

Screen resolution, performance and battery life may be reduced until a compatible driver has finished installing.

But I wasn’t sure whether perhaps that notice predated the installation of the Guest Additions. Device Manager (devmgmt.msc), running inside the VM, identified a problem with Other devices > Base System Device. I tried right-clicking on that > Update driver > Search automatically. But that turned up nothing. A search led to a DriverEasy webpage suggesting another solution that did not involve buying something from DriverEasy. This solution required me to right-click on Base System Device in Device Manager > Properties > Details tab > Property > change from “Device description” to “Hardware Ids.” That produced a handful of lines, each beginning the same: PCI\VEN_80EE&DEV_CAFE. In other words, the vendor ID was 80EE and the device ID was CAFE. With that information, I went to the PCI ID Repository. Unfortunately, that device ID did not seem to jibe with anything in their Device Classes list. The website explained that device IDs were provided by vendors. So maybe this vendor was marching to a different drummer. The vendor ID list said the vendor was InnoTek Systemberatung GmbH. The link provided there led to a page indicating that the “cafe” device was the VirtualBox Guest Service.

So apparently the Base System Device problem in Device Manager meant that the VirtualBox Guest Additions were not working or not installed correctly. With the VM running, I went again to VM menu (i.e., not VBM) > Devices > Insert Guest Additions CD Image. Then I rebooted the VM and went back into Device Manager. The problem was still there. So I shut down the VM. In VBM, I went to Settings > Storage > select VBoxGuestAdditions.iso > right-click > Remove Attachment > Remove > OK. Then I started up the VM and went back through the Insert Guest Additions CD Image process. This time, I got a message, appearing in a banner across the top of the VM, that I had not gotten or had stupidly failed to read if I did get it previously. The message said,

Could not insert the C:\Program Files\Oracle\VirtualBox/VBoxGuestAdditions.iso disk image file into the virtual machine Win10VMDK, as the machine has no optical drives. Please add a drive using the storage page of the virtual machine settings window.

I powered down the VM and went into VBM > Settings > Storage. There was no VBoxGuestAdditions.iso entry. Apparently I had been mistaken when I assumed that selecting the Guest Additions item would automatically install it. I clicked on the disc icon next to Controller: SATA (tooltip: Adds optical drive) > Leave empty > OK. I restarted the VM and, after Windows 10 was fully up and running, I went back through the Insert Guest Additions CD Image process. A hint that this worked: I got a notification, down by the system tray, reading

CD Drive (D:) VirtualBox Guest Additions

Select to choose what happens with this disc.

I clicked on that message and chose “Run VBoxWindowsAdditions.exe. Published by Oracle Corporation.” That started a VirtualBox Guest Additions 6.0.14 Setup process. I accepted the default options in that process. After a reboot, I went into the VM’s menu > Machine > Settings > Storage. It showed VBoxGuestAdditions.iso as a disc under Controller: SATA. The Device Manager problem was gone. In Win-I > System > Display > Resolution, I had resolution options up to 1280 x 960, which was pretty good for general use. Apparently it wasn’t going to get any better, at least not in the GUI: Win-I > Update & Security did not seem to have any more updates suitable for this revised configuration. An earlier post had a VBoxManage command that would apparently increase the window size, but I wasn’t sure that was necessary. The Resolution value displayed in Win-I seemed to be increased when I clicked the button in the upper right corner to expand the window to fill the desktop: now it was 1920 x 985. In Microsoft Edge, a YouTube video played correctly. The VM seemed to be functioning properly. (Later, I would encounter an indication that I probably should have unmounted the Guest Additions virtual CD, once they finished installing.)

Converting VMDK to VDI and Moving It

Several sources (e.g., StackOverflow, WithDave, VirtualBox Forum) said that the problem with VHD (above) was also a problem with the VMDK format: it was not the native format for VirtualBox, and (therefore?) a VirtualBox user would not be able to use VirtualBox tools to compact the VM occasionally, so as to restrain its tendency to bloat. The recommended solution was, ultimately, to convert the VMDK to VDI after all. It seemed that I should have done that before putting time into tweaking the VMDK. Conversion would presumably be best done before activating the VM; experience suggested that converting a VM would tend to trigger a Microsoft demand for reactivation.

For this purpose, conversion options included StarWind V2V Converter, CloneVDI, and VirtualBox’s own VBoxManage command. Given his years of experience in VDI troubleshooting, I figured that mpack’s CloneVDI would probably be the best of these options. Thus, I downloaded that (at this writing, it was version 3.02) and installed it on the Win10 host machine. In its simple interface, I indicated the VMDK as the source and named a VDI file and location as the destination. CloneVDI refused to proceed, saying “The source file does not exist.” Reading mpack’s remarks, I suspected the problem was that I had not yet powered down the VM. I did that and tried again. That did it: I was able to click the Proceed button. (I didn’t change any other settings.) In maybe ten minutes, without using the option to compact the VDI, that produced a VDI just a bit smaller than the VMDK.

Now I wanted to replace the VMDK with the VDI, in the VM that I had already created. I tried simply putting the VDI in the same folder with the VMDK and its associated files. Then I went into VirtualBox > select the Win10VMDK > Settings > Storage > remove the VMDK and add the VDI as a new SATA hard drive > start the VM. To my astonishment, that worked.

Now we were in need of some cleanup and organization. I powered down the VM. To verify that it was safe to remove the VMDK from the area of operations, I zipped it up, along with its 0.vmdk and .vmx companions. Then I restarted the VM. It still worked. So, yes, I was done with the VMDK. I powered down the VM. In VBM, I selected the VM that was based on the VHD and, since I didn’t seem to need it and was presently interested in removing clutter and freeing up disk space, I right-clicked and chose Remove > Delete All Files. Possibly I should have gone first into VBM > File > Virtual Media Manager > select the VHD > right-click > Remove.

Next, I wanted to get the new VDI into the same folder with the VirtualBox .vbox files. To do that, I repeated the steps above — basically, with the VM powered down, go into the VM’s Settings > Storage and remove the VDI; remove it also from Virtual Media Manager; move it to the desired folder; and then go back into Settings > Storage and re-add it. At the same time, in Settings, I went to General > Basic tab > change the name of the VM to correspond with the name I had given the VDI. It wasn’t Win10VMDK anymore; now it was Win10x64.

Unfortunately, that ran into problems. First, I got an error (“Could not rename the directory … Access Denied”). I thought it was because I had Windows File Manager open to that folder, but that error persisted after I closed that File Manager window. It was actually easier to just forget about the existing VM and create a new one, using the VDI in the desired folder. To get rid of the VMDK, I had to release it in Virtual Media Manager — but it wouldn’t release until I right-clicked on the VMDK VM in VBM and chose Remove.

Getting the VDI into the same folder with its attendant VM files apparently required me to create a VM without any disk files, and then add the Win10x64 VDI afterwards. There was still a lot of tinkering around, complete with closing and restarting VirtualBox, before it worked. I enabled EFI and reinstalled the Guest Additions, and then it worked as before.

This entry was posted in Uncategorized and tagged , , , , , , , , , , , , , , , . Bookmark the permalink.

1 Response to P2V: Converting a Windows 10 Physical Installation to a Virtual Machine: External Methods

  1. Anonymous says:

    Thank you! Was trying the EFI enabling with OVF and didn’t think to try it with a new VMDK file. All working.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.