Windows 10 UEFI Фізичний до KVM / libvirt Віртуальний


1

Оригінал повідомлення

Я мігрую мій комп'ютер з Windows 10 на Linux. Є кілька речей, для яких мені все ще потрібна Windows, і в даний час я подвійне завантаження, з Windows і Linux на окремих фізичних дисках. Я хотів би піти від подвійного завантаження і запустити віртуальну інсталяцію Windows 10 під KVM + libvirt + qemu.

Складніша частина тут, здається, полягає в тому, що мою установку Windows 10 було зроблено через UEFI (з таблицею розділів GPT), а не з попереднім BIOS MBR. Ось як виглядає мій диск Windows:

$ sudo parted /dev/nvme0n1 print
Model: Unknown (unknown)
Disk /dev/nvme0n1: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size    File system  Name                          Flags
 1      1049kB  524MB  523MB   ntfs         Basic data partition          hidden, diag
 2      524MB   628MB  104MB   fat32        EFI system partition          boot, esp
 3      628MB   645MB  16.8MB               Microsoft reserved partition  msftres
 4      645MB   500GB  499GB   ntfs         Basic data partition          msftdata

Оскільки вона була налаштована як UEFI, мабуть, існують додаткові кроки для віртуалізації, оскільки libvirt не підтримує UEFI з коробки. Я намагався експортувати кожну з перелічених вище розділів як зображення qcow2, з такою командою:

$ qemu-img convert -f raw -O qcow2 /dev/nvme0n1p1 win10_part1.qcow2

І повторюється для всіх чотирьох розділів. Потім я створив віртуальну машину під vir-manager, імпортуючи всі чотири диски qcow2. Я встановив пакет "ovmf" для свого дистрибутива (Manjaro) і додав цей рядок у XML-файл конфігурації віртуальної машини, в розділі "os":

<loader type='rom'>/usr/share/ovmf/x64/OVMF_CODE.fd</loader>

Коли я завантажую віртуальну машину, я бачу заставку TianoCore. Але він просто впадає в оболонку grub2, а не знаходить завантажувач Windows.

Я також спробував завантаження цієї віртуальної машини з Windows 10 встановити ISO, сподіваючись, що я міг "відновити" систему для завантаження. Але це не спрацювало.

Я впевнений, що я щось відсутній. Ще краще було б перетворити це на завантаження MBR, просто щоб уникнути залежності OVMF.

Редагувати / оновити ...

За коментарем Ділана, я зрозумів, що він працює, але на цьому шляху з'явився ряд невеликих питань, я думав, що я відправлю їх тут, якщо інші мають подібні проблеми.

Першим кроком, як писав Ділан, було створення образу весь диск , а не окремі диски для розділів. Я використав цю команду:

qemu-img convert -f raw -O qcow2 /dev/nvme0n1 win10_import.qcow2

Потім я створив віртуальну машину у virt-manager, вказавши вищезгаданий образ диска ("win10_import.qcow2") як мій диск.

Далі потрібно було використовувати ОВМФ (TianoCore) прошивки UEFI. Це було зроблено шляхом встановлення пакунка ovmf ("ovmf" на Manjaro), а потім додавання його у визначення XML віртуальної машини:

  <os>
    <type arch='x86_64' machine='pc-q35-3.0'>hvm</type>
    <loader type='rom'>/usr/share/ovmf/x64/OVMF_CODE.fd</loader>
  </os>

Після цього Windows буде досі аварії під час завантаження, з bluescreen і помилка "SYSTEM THREAD EXCEPTION НЕ ВИКОНАНО". З якоїсь причини налаштування процесора "Копіювати процесор центрального процесора" не подобається. Я змінив на "core2duo", і це завантажилося. Зараз я використовую "SandyBridge" і це також працює. (Для чого це коштує, я створив іншу, окрему Win10 VM роблять свіжу установку з нуля. Це VM працювала з "Копіювати конфігурацію центрального процесора". Мій процесор AMD Ryzen 5 2400G.)

Наступною проблемою, з якою я зіткнувся, було те, що Windows 10 пробігла нестерпно. Якось мені вдалося створити VM з гіпервізором "QEMU TCG", а не з "KVM". Це має сенс, як і перший емуляція і жахливо повільний, в той час як останній - віртуалізація, яка підтримується апаратним забезпеченням. (Як це сталося: під час спроби змусити це працювати, я також зробив оновлення BIOS на фізичній системі, яка скидає всі мої налаштування BIOS, один з яких вимкнув віртуалізацію (називається "SVM" в моєму BIOS). , Я зміг використати майже рідний швидкісний KVM гіпервізор.)

Наступним питанням було те, що дозвіл екрана застрягло на рівні 800x600. Windows не дозволить мені змінити його. Я міг би зробити одноразове виправлення, натиснувши вихід відразу після завантаження машини, коли з'явиться сплеск TianoCore. Це приводить мене до налаштувань UEFI, де я можу змусити більш високу роздільну здатність. Але це не є постійним виправленням.

Оскільки моя віртуальна машина вказала QXL як відеопристрій, мені потрібно було встановити драйвери QXL у Windows. Ця сторінка, Створення віртуальних машин Windows за допомогою драйверів virto пояснює, як це зробити. Коротка версія: скачати isio на хост-машині. Додайте його до віртуальної машини як привід компакт-дисків. Потім, завантажившись у віртуальну машину, перейдіть до потрібної папки на компакт-диску і встановіть всі необхідні драйвери VirtIO. Зокрема, для відео QXL на Windows 10 папка "qxldod" має потрібний драйвер.

Відповіді:


1

QEMU / Libvirt очікує, що ви надасте віртуальний диск: ваші файли QCOW2 повинні бути дисками, а не розділами. Роблячи те, що ви зробили, ви отримали 4 файли qcow2, кожен з яких має один розділ. Ви зламали попередню структуру, не дивно, що GRUB більше не може завантажитися.

Я пропоную вам перетворити весь фізичний диск на один файл QCOW2, а потім прикріпіть цей віртуальний диск до вашої VM.

Ви повинні бути в змозі видалити файл GRUB EFI з розділу EFI (див. Libguestfs tools) і отримати версію меню завантаження, оскільки завантажувач завантажувача Windows повинен бути завантажений UEFI VM.


0

Якщо ще хтось спотикається з цим питанням, існує ще одна альтернатива для використання рідної вікна як Linux у Linux:

  1. Зображення цілого пристрою, як за прийнятої відповіді Ділана.
  2. Запустіть віртуальну машину з вихідного сховища.

Мені вдалося # 2 вище, але це може бути досить залученим. Це стає досить складним і ризиком, якщо як Linux, так і Windows спільно використовують один і той же пристрій.

Варто лише додаткових зусиль з різних причин:

  • Вже є і схожа на подвійну настройку завантаження.
  • Потрібно запускати вікна безпосередньо на апаратному забезпеченні.
    • Графічна продуктивність для ігор (і не мають материнської плати / налаштування, здатних виконувати PCI-перехід з 2x GPU тощо).
    • Надто чутливі звукові програми, такі як Skype для бізнесу, які працюють слабко через віртуалізовані аудіопристрої.
  • Бажаєте зручності віртуальної машини для запуску інших менш вимогливих додатків, таких як офіс MS тощо.

Існували численні застереження:

  • У мене була боротьба з отриманням вікон, щоб залишитися активованими, оскільки це, очевидно, прив'язує ліцензії до апаратних засобів. Намагання з додаванням серійних номерів материнської плати / BIOS, точної моделі процесора та серійних номерів пристроїв зберігання, здавалося, допомогло.
  • Додайте правила udev, щоб зробити Linux / Nautilus / Gnome менеджером файлів ігнорувати розділи Windows.
  • Через параною (занепокоєні оновлення для Windows можуть вплинути на налаштування grub / boot), я не просто роздав весь диск з VM. Замість цього:
    • Я клонував таблицю розділів (GPT) і розділ EFI на файли, а також створив підроблений файл зображення пристрою.
    • Використовував драйвер циклічного відтворення для обробки клонованих зображень як пристроїв
    • Використовував MD (multi-device) драйвер через mdadm лінійний setup до ланцюга всі необхідні частини разом як гібрид imaged та сирий пристрій для VM. Напр. md0 побудований з <GPT table clone image/loopback> + <recovery raw> + <EFI clone image/loopback> + <windows system raw> + <end of device GPT backup table/loopback>.
    • Використовували gdisk і testdisk для виправлення / налаштування таблиць розділів за потреби.
    • 1803 Windows 10 оновлення кинув в додатковий розділ я повинен був пристосуватися до! Після встановлення Windows 10 April Update з'явиться новий розділ . Потрібно знову виправити ...

Я використовував подібну установку на 2-й системі, але зробив своє життя набагато простіше, маючи 2 окремих пристроїв зберігання даних, один для Linux, інший для Windows.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.