Windows 10 P2V
There is a single Windows 10 system in the house. Running on a dual core CPU I wanted to move Windows from physical to virtual (P2V). The dual core system is functional but comparatively slow, supporting only SATA II disks and an Intel GMA 4500 video controller. An SSD would improve much, but using a VM on better hardware provides a faster system. Running a single computer is more energy efficient than running two.
The dual core computer originally came with Windows 7 installed. Updating Windows 7 to Windows 10 succeeded and resulted in a Windows 10 digital “entitlement” license. The currently installed Windows 10 version is 1909.
The Windows license allows using one instance on one physical or virtual device. Migrating Windows from physical to virtual is within the scope of the license.
There is much information online about P2V migrations. The stinker with Windows is license activation. Despite the licensing would the activation algorithm allow the move?
I read much about ways to masquerade virtual systems. I long have known how to spoof some machine hardware. Yet fully fooling software that a virtual machine (VM) is acting like a physical system is a challenge. This project is not about fooling malware authors. The sole question is how much of the original machine must be spoofed to satisfy the Windows license algorithm?
One suggestion to reactive a license is creating a Microsoft account and attach the license to that account. The license then travels with the online account. Thank you, no.
How to start this project? I could convert the installed disk to a virtual disk or I could clone the disk and use raw disk access.
I cloned the installed 320 GB disk to a disk image file. I converted the image file to a dynamically sized virtual vdi disk. The result was a 41 GB file. The virtual vdi disk functioned fine. I did not like this approach because of the impact on backups. That is a huge file. I never had a VM that big on my personal systems. Also uncomfortable is the full virtual disk size is the size of the original physical hard disk — 320 GB.
Next I cloned the installed hard disk to a spare disk. With the cloned disk and VirtualBox I used raw disk access to create a VM. No disk conversion involved. The approach worked well and provided nice disk I/O despite being a spare SATA II disk.
I tinkered with masquerading more of the hardware. A little bit here and there. I learned a few things.
Continually my efforts resulted in Windows not being activated after my P2V effort.
I was ready to resign and abandon the spoofing attempts. I decided to perform a straightforward P2V conversion using raw disk access. I hoped a manual activation would succeed.
Then I had a light bulb moment. I had tinkered much in a continual manner. I wondered whether the cloned disk was “contaminated.”
I decided to start fresh the next day.
In my effort to move Windows 10 from physical to virtual, I again cloned the installed 320 GB disk. I removed and recreated the vmdk raw disk image for the VM. I did not remove any hardware spoofing parameters in the VM configuration. I booted the VM.
Windows would not fully boot. Something was awry with the hardware detection. Not surprising because contrary to several online recommendations I had not performed any preparations for the move. I selected the “safe boot” option. Windows successfully booted. I shrugged and rebooted. Windows booted normally. I checked the activation status.
I sat somewhat stunned. Windows reported being activated. My hardware masquerading had succeeded. I only needed to start with a fresh disk clone.
Curious, I installed the VirtualBox guest additions (GA). Would Windows remain activated after installing and rebooting? Windows remained activated.
I wondered how much of the hardware spoofing I could remove to better emulate the real underlying hardware.
I deleted the CPU ID spoofing. Windows remained activated. This was good news because I hope to update the office computer to an AMD system. The CPU was spoofed as GenuineIntel, which likely would cause havoc on an actual AuthenticAMD system.
I deleted additional CPU parameters generated from dmidecode. Windows remained activated.
I again cloned the installed disk but with a different hard disk. I modified the related VM disk extra data. Windows remained activated.
I deleted all hard disk spoofing. Windows remained activated.
I deleted all optical disk spoofing. Windows remained activated.
At this point the activation algorithm did not seem designed to notice I had installed the VirtualBox GA (VirtualBox Graphics Adapter WDDM) or had changed the CPU (Intel(R) Core(TM)2 Duo CPU E8400 @3.00GHz to Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz), hard disk (VBOX HARDDISK), and optical disk VBOX CD-ROM.
The remaining VM extra data tweaks included BIOS, board, chassis, and system spoofing.
I removed the option to the external SLIC table file. Windows remained activated.
I removed “system” related tweaks DmiSystemProduct, DmiSystemSKU, DmiSystemSerial, DmiSystemUuid, DmiSystemVendor, and DmiSystemVersion. Windows no longer remained activated.
I restored those values. Windows again was activated. This seems to indicate the original activation hash remains unchanged.
I removed “chassis” related tweaks DmiChassisAssetTag, DmiChassisSerial, and DmiChassisVendor. Windows remained activated.
I removed “board” related tweaks DmiBoardAssetTag, DmiBoardProduct, DmiBoardSerial, and DmiBoardVendor. Windows remained activated.
I removed “BIOS” related tweaks DmiBIOSReleaseDate, DmiBIOSReleaseMajor, DmiBIOSReleaseMinor, DmiBIOSVendor, DmiBIOSVersion. Windows no longer remained activated.
I restored those values. Windows again was activated.
The important values to which the activation hash seemed to be based:
DmiBIOSReleaseDateDmiBIOSReleaseMajorDmiBIOSReleaseMinorDmiBIOSVendorDmiBIOSVersion
DmiSystemProductDmiSystemSKUDmiSystemSerialDmiSystemUuidDmiSystemVendorDmiSystemVersion
Or some combination thereof. I did not test further. The activation hash seems to be based only on BIOS and mainboard information.
There was one more test. I connected the VM virtual Ethernet cable and allowed Windows to update. I hoped that would not in some way affect the activation. As usual the update took a long time. Odd how on a Linux system a user can go months without updating or patching and the update takes only several minutes.
After updating and rebooting the system remain activated.
I reconsidered using the large vdi disk. Ideally raw disk access uses an additional physical disk and contradicted my goal of using less energy. While the vdi disk consumes significant disk space, backing up another separate disk introduces new challenges with the existing backup strategy. One way or another I need to address backing up this system, something I mostly ignored with the original physical computer.
In anticipation of reducing the backup footprint I repeated the steps to clone the disk partitions and the steps to create the vdi disk. On the original computer I shrunk the Windows C: partition to about 120 GB. The smallest spare disk I had was a 160 GB laptop spinner. That reduced the footprint of the virtual vdi disk to about 140 GB, the maximum this virtual disk could grow.
There are some security concerns. The original Windows computer was on a VLAN. I never wanted a Windows system near the house LAN. With now being virtual the only sane network option is using NAT to keep the Windows system isolated. NAT allows access to the host operating system’s loopback interface but outside zero-day explots probably is nothing to worry about.
Sharing the clipboard helps much with seamless operations but allowing the guest to access the host clipboard is a security concern.
Sharing files is helpful. VirtualBox supports shared folders. Sharing folders needs to be done carefully so the guest cannot see any other host files. A dedicated shared folder is best.
In all I am satisfied with the project.
Why bother with this escapade? I might need to use Windows for employment. Doesn’t change my mind about Windows. I really hate that chicken Windows.
Posted: Category: Usability Tagged: Migrate, Windows
Next: Detecting NFS Clients Redux
Previous: Copying Console Text to the Clipboard