Boot windows on virt-manager from an image that fetched from existing Windows on a different computer

Question

I have a PC laptop with Windows 10, it has two hard drives, one for windows that is separated with UEFI, windows and data partition, and another hard drive that has some more apps installed on it.

I am trying to duplicate that system to be able to run it on virt-manager under Gentoo Linux.

So first I duplicated the hard drives using disk2hd (https://docs.microsoft.com/en-us/sysinternals/downloads/disk2vhd), it created two separated VHDX files for each hard drive.

Then I converted these images to qcow2, a format that virt-manager is familiar with using qemu-img with these flags:

qemu-img convert -p -f vhdx -O qcow2

I mounted the qcow2 and verified that the files are presented and that the images are correct.

then I ran virt-manager, enabled UEFI and configured it to boot from the main hard drive. windows fails to boot. when I tried to run windows recovery it could not fix the startup failure.

I googled and I found that the only real way to fix windows boot is to download windows, and run an upgrade on the current windows system.so I did that, I downloaded the ISO, booted it on virt-manager but I could not upgrade, it failed to detect a previous windows installation on the drive.

Then I thought about reinstalling Windows on that partition, and then overwriting the new Windows files with the old ones by deleting the ProgramData, Users, Program Files and Windows directory and replacing it with the old backup.

The failure that I had with that is that the current drive is divided to UEFI, Windows and data partitions and it gave me an error that it could not install Windows on the partition that the previous Windows installation existed it, then I mounted the qcow2 image of the main drive, deleted all the partition table, reinstalled Windows on that drive while allowing the Windows installation to re-partition the drive automatically and then to replace the files, but after replacing the files Windows did not boot again and showed exactly the same symptoms.

virt-manager could run Windows properly because when I installed a new version of Windows, it executed properly and I had no problems, but I am trying to run the same installation of Windows from that other computer.

So for now I have no idea what else I can do to resolve this problem so any information would be greatly appreciated.

update 1

I am trying to preserve some accounting app that I don't have an upgrade license for that uses MS SQL that I don't have the username and password for. and in general I think it would be fun to know how to preserve a Windows computer on a VM.

So regarding error messages.. When Windows issuing startup repair the only error that I see is

Startup Repair couldn't repair your PC

When I start Windows installation and try to upgrade current Windows I get:

The upgrade option isn't available if you start your computer using Windows installation media.

When I try to install Windows on the same partition that the Windows was already installed to try and the move windows.old directory to Windows I get

Windows cannot be installed on this disk. The selected disk is of the GPT partition style.

update 2

Credit to all the wonderful answers, I prefer to be able to resolve working with VHDX then using a different backup software and play with that.

My hard drive literally crashed OS I backed up the VHDX files again and try on a different Gentoo machine that I have.

So from the beginning, I noticed that the laptop has Windows 10 Home Edition 64 bit Hebrew edition and that it uses UEFI.

So I created a new Windows 10 VM with Q35 Chipset and Firmware UEFI x86_64: /usr/share/qemu/edk2-x86_64-code.fd created 2 SATA drives and pointed them to the original VHDX files instead of converting it to qcow2 first, and allowed to boot from all drives and set the CDROM to boot from first.

First I booted with Linux Gentoo mini CD just to confirm that the drives are readable from the VHDX files and they are not, so I re-created the qcow2 files, booted from Gentoo Linux and the drives where readable. (For some reason I thought that QEMU supports VHDX out of the box).

So booted Gentoo Linux ISO again and checked the drives and now I see partitions.

In /dev/sda I have one NTFS partition at /dev/sda1 labeled Microsoft Basic Data. this is for all the other programs that I installed that laptop.

and on /dev/sdb I have the following:

/dev/sdb1 vfat 260M EFI System
/dev/sdb2 GUID:63 16M Microsoft reserved
/dev/sdb3 ntfs 118.1G Microsoft basic data
/dev/sdb4 ntfs 865M Windows recovery environment

So Windows is installed on the 2nd drive on /dev/sdb3, I mounted and verified. Since sdb has the EFI partition I assume that the boot should be fixed in that drive and I can remove /dev/sda from the bootable drives in the VM. so I did that and boot Windows installation ISO.

Tried executing Startup Repair again, it showed Diagnosing your PC and then Attempting Repair and then it rebooted and now it actually works. I don't know if it's because of my failed drive, because I didn't see any related errors, but you guys made my understand how important it is to check that the original laptop uses UEFI and to keep using the original drive's partitions and hard drives exact order. You helped me not to spread out and try stuff that will mess things up like repartition the drive and waste a lot of time for nothing.

I actually wrote the responses here live while re-trying everything and I'm so glad it works.

Answer 1

One, or both, of these two factors are likely at play, with #2 being the boot issue:

1. Windows is not intended to be imaged on one system and used on a different system, VM or otherwise, without first running SysPrep on the cloned OS partition prior to it booting on the new system
2. A BCD Store [UEFI] issue, as device volume paths and GUIDs are no longer accurate within the BCD Store [Boot\BCD || EFI\Microsoft\Boot\BCD] when Windows is moved/applied to a new partition:
   • Inaccuracies within the BCD Store will cause boot failure during boot Phase 2:
     Boot loader phase → Windows Boot Manager
     
   • BCD Store volume path and GUID example:

     # Full volume paths:
       # \\?\GLOBALROOT\Device\Harddisk#\HarddiskVolume#
       # \\?\GLOBALROOT\Device\Harddisk#\Partition#
     
     PS $  BcdEdit /Enum
     
       Windows Boot Manager
       --------------------
       identifier              {bootmgr}
       device                  partition=\Device\HarddiskVolume8
       path                    \EFI\Microsoft\Boot\bootmgfw.efi
       description             Windows Boot Manager
       locale                  en-US
       inherit                 {globalsettings}
       default                 {current}
       resumeobject            {e335a64a-37dc-11eb-bd2a-85edee9cbf64}
       displayorder            {current}
       toolsdisplayorder       {memdiag}
       timeout                 30
     
       Windows Boot Loader
       -------------------
       identifier              {current}
       device                  partition=C:
       path                    \Windows\system32\winload.efi
       description             Windows 10
       locale                  en-US
       inherit                 {bootloadersettings}
       recoverysequence        {55541c35-9fa7-11eb-9281-8086f283f968}
       displaymessageoverride  CommandPrompt
       recoveryenabled         Yes
       isolatedcontext         Yes
       allowedinmemorysettings 0x15000075
       osdevice                partition=C:
       systemroot              \Windows
       resumeobject            {e335a64a-37dc-11eb-bd2a-85edee9cbf64}
       nx                      OptIn
       bootmenupolicy          Standard
       hypervisorlaunchtype    Auto
     

To resolve:

Perform the BCD store fix [#3] first, but the VHDX should be SysPrep'd, as that is the correct way to clone the OS to a different machine [physical or virtual]:
^{(I've listed the steps in their correct chronological order)}

1. SysPrep the VHDX:
   1. Boot the cloned VHDX on the same system it was cloned from and log in
   2. +R → Open: %WinDir%\System32\Sysprep\sysprep.exe → OK
      1. System Cleanup Action: Enter System Out-of-Box-Experience (OOBE)
      2. Shutdown Options: Shutdown
      3. OK
   3. After SysPrep finishes, boot back to the original Windows install and re-create the VM image from the SysPrep'd VHDX
      
      
2. Firmware settings [BIOS || UEFI] in the VM must match:
   If Windows was installed on a UEFI PC, the VM must be UEFI with CSM [Legacy] Mode disabled
   • CSM Mode should never be enabled, as its sole purpose was to support distros that didn't yet support EFI boot circa <2017; it emulates BIOS' 16bit architecture within a 32bit environment and doing so will cause performance degradation (boot times increase by 400%+, GPT cannot be used in Windows, etc.)
     
     
3. Boot to WinRE: Command Prompt and execute Methods 2 & 3:
   ^{If WinRE fails to boot, boot an Install ISO/USB [WinPE] and open a terminal via Ctrl+Shift+F10}
   [BootRec | BcdBoot]
   • BIOS:

     BootRec /FixMBR && BootRec /FixBoot && BootRec /RebuildBCD
     

   • UEFI:

     BootRec /FixMBR && BootRec /RebuildBCD
     

     If needed, fixing the boot directory requires extra steps for EFI boot:

     ::# Mount EFI partition at Y:
         Diskpart
     
           Lis Vol
           Sel Vol #
           Assign Letter=Y
           Exit
     
     ::# Enter EFI directory and repair EFI boot structure:
         Cd /d "Y:\EFI\Microsoft\Boot"
         BootRec /FixBoot
     
         ::# If Access Denied error occurs (C: is OS partition, refer to Lis Vol):
             BcdBoot C:\Windows /s C: /f UEFI
     
     ::# Resolve any other boot issues:
         BootRec /FixMBR && BootRec /RebuildBCD
     
     ::# Remove EFI mountpoint and reboot:
         DiskPart
     
           Sel Vol Y
           Remove
           Exit
     
         Exit
     

     
     

---

While Startup Repair could be used, there's no guarantee it will fix a BCD Store that isn't corrupted, often returning it didn't find, or couldn't fix, an issue:
^{(I've never found a man page on what Startup Repair does on the backend - please comment if knowing)}

• It's well-known the BCD Store is almost always the cause of boot issues after moving/applying the OS to a new partition (#2 at answer's top), so it's simply more efficient to run BootRec directly, taking ~2m from start to finish, versus much longer for Startup Repair to run and the user to determine if it fixed the issue
• Startup Repair doesn't list what it does afterward, instead logging to:

  X:\Windows\System32\LogFiles\Srt\Srttrail.txt
  

  To determine what was/wasn't done, it requires accessing WinRE's Command Prompt and opening the log within NotePad; should this not be done, the log is lost upon rebooting since X: is a RAM drive

All of this takes exponentially longer [less-efficient] than simply running BootRec directly to fix the most likely problem, an issue with the BCD Store (work smarter, not harder).