Запуск Windows в virt-manager с образа, полученного с существующего Windows на другом компьютере.

У меня есть ноутбук с Windows 10, в нем два жестких диска: один для Windows, который разделен на UEFI, раздел Windows и раздел данных, и другой жесткий диск, на котором установлено еще несколько приложений.

Я пытаюсь дублировать эту систему, чтобы иметь возможность запускать ее на virt-manager под Gentoo Linux.

Сначала я дублировал жесткие диски с помощью disk2hd (https://docs.microsoft.com/en-us/sysinternals/downloads/disk2vhd), он создал два отдельных файла VHDX для каждого жесткого диска.

Затем я конвертировал эти образы в формат qcow2, который поддерживает virt-manager, с помощью qemu-img с этими флагами:

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

Я смонтировал qcow2 и проверил, что файлы отображаются, и что образы правильные.

Затем я запустил virt-manager, включил UEFI и настроил его на загрузку с основного жесткого диска. Windows не загружается. Когда я попытался выполнить восстановление Windows, оно не смогло исправить ошибку запуска.

Я решил поискать в интернете и обнаружил, что единственный реальный способ исправить загрузку Windows – это загрузить Windows и выполнить обновление на текущей системе Windows. Я так и сделал, скачал ISO, загрузил его на virt-manager, но не смог выполнить обновление, так как система не обнаружила предшествующую установку Windows на диске.

Тогда я подумал о переустановке Windows на этот раздел, а затем о замене новых файлов Windows на старые, удалив директории ProgramData, Users, Program Files и Windows и заменив их старой резервной копией.

Проблема, с которой я столкнулся, заключается в том, что текущий диск разделен на UEFI, Windows и раздел данных, и мне выдало ошибку, что не удалось установить Windows на раздел, на котором была предыдущая установка Windows. Тогда я смонтировал qcow2 изображение основного диска, удалил всю таблицу разделов, переустановил Windows на этот диск, разрешив установке Windows автоматически пересоздать разделы, а затем заменить файлы, но после замены файлов Windows снова не загрузился и показал точно те же симптомы.

virt-manager мог запустить Windows должным образом, ведь когда я установил новую версию Windows, она работала правильно и у меня не было проблем, но я пытаюсь запустить ту же установку Windows с другого компьютера.

Так что на данный момент у меня нет никаких идей, что еще можно сделать, чтобы решить эту проблему, поэтому любая информация будет очень полезна.

Обновление 1

Я пытаюсь сохранить одно бухгалтерское приложение, для которого у меня нет лицензии на обновление, а оно использует MS SQL, для которого у меня нет имени пользователя и пароля. В общем, мне было бы интересно узнать, как сохранить Windows компьютер на виртуальной машине.

Что касается сообщений об ошибках.. Когда Windows выдает восстановление на запуск, единственная ошибка, которую я вижу, – это

Восстановление на запуск не смогло восстановить ваш ПК

Когда я начинаю установку Windows и пытаюсь обновить текущую Windows, я получаю:

Опция обновления недоступна, если вы запускаете компьютер с использованием установочных носителей Windows.

Когда я пытаюсь установить Windows на тот же раздел, на котором уже была установлена Windows, чтобы затем переместить директорию windows.old в Windows, я получаю

Windows не может быть установлена на этом диске. Выбранный диск имеет стиль разбиения GPT.

Обновление 2

Благодарю за все замечательные ответы, я предпочел бы разрешить проблему, работая с VHDX, чем использовать другое программное обеспечение для резервного копирования и возиться с ним.

Мой жесткий диск буквально сломал ОС, я снова сохранил файлы VHDX и попробовал на другой машине Gentoo, которая у меня есть.

Итак, с самого начала я заметил, что на ноутбуке установлена Windows 10 Home Edition 64 бита на иврите и что он использует UEFI.

Я создал новую виртуальную машину Windows 10 с чипсетом Q35 и прошивкой UEFI x86_64: /usr/share/qemu/edk2-x86_64-code.fd, создал 2 SATA диска и указал их на оригинальные файлы VHDX вместо того, чтобы сначала конвертировать их в qcow2, и разрешил загрузку со всех дисков, установив CDROM в качестве первого устройства для загрузки.

Сначала я загрузил мини CD Gentoo Linux, чтобы подтвердить, что диски читаются из файлов VHDX, и они не читаются, поэтому я пересоздал файлы qcow2, загрузился с Gentoo Linux, и диски были читаемыми. (По какой-то причине я думал, что QEMU поддерживает VHDX из коробки).

Я снова загрузил ISO Gentoo Linux и проверил диски, и теперь я вижу разделы.

На /dev/sda у меня есть один раздел NTFS на /dev/sda1, помеченный как Microsoft Basic Data. Это для всех остальных программ, которые я установил на этот ноутбук.

А на /dev/sdb у меня следующее:

/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

Таким образом, Windows установлена на 2-м диске на /dev/sdb3, я смонтировал и проверил. Поскольку sdb имеет EFI-раздел, я предполагаю, что загрузка должна быть исправлена на этом диске, и я могу удалить /dev/sda из загрузочных дисков в виртуальной машине. Я так и сделал и загрузил ISO установки Windows.

Попробовал снова выполнить Startup Repair, он показал Диагностика вашего ПК, затем Попытка восстановления, и затем перезагрузился, и теперь это действительно работает. Я не знаю, связано ли это с моим сломанным диском, поскольку я не обнаружил никаких связанных ошибок, но вы показали мне, как важно проверять, что оригинальный ноутбук использует UEFI и продолжать использовать оригинальные разделы и жесткие диски в точном порядке. Вы помогли мне не распыляться и не пытаться что-то делать, что бы все испортить, как например, переразбивать диск и тратить много времени впустую.

На самом деле я писал ответы здесь на ходу, пока снова все перепробовал, и мне так приятно, что это работает.

Один или оба этих фактора могут быть причиной, причем #2 является проблемой загрузки:

1. Windows не предназначена для создания образов на одной системе и использования на другой системе, ВМ или другой, без предварительного выполнения SysPrep на клонированном разделe ОС перед его загрузкой на новой системе.
2. Проблема с хранилищем BCD [UEFI], как пути объема устройства и GUID больше не являются точными в пределах хранилища BCD [Boot\BCD || EFI\Microsoft\Boot\BCD], когда Windows перемещается/применяется к новому разделу:
   • Неточности в хранилище BCD приведут к сбоям загрузки при загрузке на фазе 2:
     Фаза загрузчика → Диспетчер загрузки Windows
     
   • Пример объема пути и GUID хранилища BCD:

     # Полные пути к томам:
       # \\?\GLOBALROOT\Device\Harddisk#\HarddiskVolume#
       # \\?\GLOBALROOT\Device\Harddisk#\Partition#
     
     PS $  BcdEdit /Enum
     
       Диспетчер загрузки Windows
       --------------------
       identifier              {bootmgr}
       device                  partition=\Device\HarddiskVolume8
       path                    \EFI\Microsoft\Boot\bootmgfw.efi
       description             Диспетчер загрузки Windows
       locale                  en-US
       inherit                 {globalsettings}
       default                 {current}
       resumeobject            {e335a64a-37dc-11eb-bd2a-85edee9cbf64}
       displayorder            {current}
       toolsdisplayorder       {memdiag}
       timeout                 30
     
       Загрузчик Windows
       -------------------
       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
     

Для разрешения:

Сначала исправьте хранилище BCD [#3], но VHDX должен быть подготовлен с помощью SysPrep, так как это правильный способ клонирования ОС на другой компьютер [физический или виртуальный]:
^{(Я перечислил шаги в правильном хронологическом порядке)}

1. Сделайте SysPrep для VHDX:
   1. Загрузите клонированный VHDX на той же системе, с которой он был склонирован, и войдите в систему.
   2. +R → Открыть: %WinDir%\System32\Sysprep\sysprep.exe → ОК
      1. Действие по очистке системы: Введите опыт использования системы без коробки (OOBE)
      2. Опции завершения работы: Завершение работы
      3. ОК
   3. После завершения SysPrep загрузитесь обратно на оригинальную установку Windows и заново создайте образ ВМ из подготовленного VHDX
2. Настройки прошивки [BIOS || UEFI] в ВМ должны совпадать:
   Если Windows была установлена на компьютере с UEFI, ВМ также должна быть UEFI с отключенным режимом CSM [наследие].
   • Режим CSM никогда не должен быть включен, так как его единственная цель – поддержка дистрибутивов, которые еще не поддерживают загрузку EFI примерно до 2017 года; он эмулирует 16-битную архитектуру BIOS в 32-битной среде, и это приведет к ухудшению производительности (время загрузки увеличивается более чем на 400%, GPT не может быть использован в Windows и т. д.)
3. Загрузитесь в WinRE: Командная строка и выполните методы 2 и 3:
   ^{Если WinRE не удается загрузить, загрузитесь с установочного ISO/USB [WinPE] и откройте терминал через Ctrl+Shift+F10}
   [BootRec | BcdBoot]
   • BIOS:

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

   • UEFI:

     BootRec /FixMBR && BootRec /RebuildBCD
     

     Если необходимо, исправление загрузочной директории требует дополнительных шагов для загрузки EFI:

     ::# Смонтировать EFI-раздел на Y:
         Diskpart
     
           Lis Vol
           Sel Vol #
           Assign Letter=Y
           Exit
     
     ::# Войти в директорию EFI и восстановить структуру загрузки EFI:
         Cd /d "Y:\EFI\Microsoft\Boot"
         BootRec /FixBoot
     
         ::# Если возникает ошибка доступа (C: является разделом ОС, обратитесь к Lis Vol):
             BcdBoot C:\Windows /s C: /f UEFI
     
     ::# Решить любые другие проблемы с загрузкой:
         BootRec /FixMBR && BootRec /RebuildBCD
     
     ::# Удалить точку монтирования EFI и перезагрузить:
         DiskPart
     
           Sel Vol Y
           Remove
           Exit
     
         Exit
     

Хотя Восстановление на запуск может быть использовано, нет никакой гарантии, что оно исправит хранилище BCD, которое не повреждено, часто возвращая, что не нашло или не смогло исправить проблему:
^{(Я никогда не находил страниц руководства о том, что именно делает Восстановление на запуск на заднем плане – пожалуйста, прокомментируйте, если знаете)}

• Общеизвестно, что хранилище BCD почти всегда является причиной проблем с загрузкой после перемещения/применения ОС на новый раздел (#2 вверху ответа), поэтому просто более эффективно запускать BootRec непосредственно, что занимает ~2 минуты с начала до конца, по сравнению с гораздо большим временем, необходимым для Восстановления на запуск, чтобы запустить его и пользователю решить, исправило ли это ошибку
• Восстановление на запуск не указывает, что оно делает впоследствии, вместо этого записывая в:

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

  Для определения того, что было сделано или не сделано, необходимо получить доступ к командной строке WinRE и открыть журнал в NotePad; если этого не сделать, журнал будет утерян после перезагрузки, так как X: является RAM-диском

Все это занимает значительно больше времени [менее эффективно], чем просто запустить BootRec напрямую, чтобы исправить наиболее вероятную проблему, проблему с хранилищем BCD (работайте умнее, не усерднее).