web-dev-qa-db-ja.com

Windows 10 UEFI物理からKVM / libvirt仮想

元の投稿

PCをWindows 10からLinuxに移行しています。 Windowsがまだ必要なものがいくつかありますが、現在、WindowsとLinuxを別々の物理ディスクに置いて、デュアルブートしています。デュアルブートを回避し、KVM + libvirt + qemuで仮想化されたWindows 10インストールを実行します。

ここでトリッキーな部分は、私のWindows 10のインストールが、レガシーBIOS MBRではなく、UEFI（GPTパーティションテーブルを使用）を介して行われたことです。私の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

そして、4つのパーティションすべてに対して繰り返されます。次に、virt-managerの下に仮想マシンを作成し、4つすべてのqcow2ドライブをインポートしました。ディストリビューション（Manjaro）の「ovmf」パッケージをインストールし、仮想マシンのXML構成ファイルの「os」セクションに次の行を追加しました。

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

仮想マシンを起動すると、TianoCoreスプラッシュ画面が表示されます。しかし、Windowsブートローダーを見つけるのではなく、単にgrub2シェルに移動します。

また、システムを「修復」して起動できることを期待して、Windows 10インストールISOからこのVMを起動してみましたが、うまくいきませんでした。

私は何かが欠けていると確信しています。 OVMFの依存関係を回避するために、これをMBRブートに変換することをお勧めします。

編集/更新...

Dylanのコメントによると、私はそれを機能させましたが、いくつかの小さな問題が途中で出てきました。他の人が同様の問題を抱えている場合に備えて、ここに投稿すると思いました。

最初のステップは、ディランが書いたように、個々のパーティションごとのディスクではなく、ディスク全体のイメージを作成することでした。私はこのコマンドを使用しました：

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

次に、virt-managerで仮想マシンを作成し、上記のディスクイメージ（ "win10_import.qcow2"）をドライブとして指定しました。

次に、OVMF（TianoCore）UEFIファームウェアを使用しました。これは、ovmfパッケージ（Manjaroの「ovmf」）をインストールし、それを仮想マシンの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はブート中にstillクラッシュし、ブルースクリーンと「SYSTEM THREAD EXCEPTION NOT HANDLED」というエラーが表示されます。何らかの理由で、「ホストCPU構成のコピー」CPU設定が好きではありませんでした。 「core2duo」に変更して起動しました。現在、「SandyBridge」を使用していますが、これも機能します。 （それだけの価値があるため、別のWin10を作成しましたVM新規インストールを最初から行います。それVM「Copy Host CPU configuration」で動作しました。私のCPUはAMD Ryzen 5 2400Gです。）

次に遭遇した問題は、Windows 10の実行速度が耐えられないほど遅いことでした。どういうわけか、私はなんとかVMを "KVM"ではなく "QEMU TCG"ハイパーバイザーで作成しました。これは前者がエミュレーションと非常に遅いですが、後者は真のハードウェアアシスト仮想化です（これが行われた方法：これを機能させるために、物理システムでBIOSアップグレードも実行しました。これにより、すべてのBIOS設定がリセットされ、その1つが無効になりました仮想化（私のBIOSでは「SVM」と呼ばれています）。これを修正すると、ネイティブに近い速度を使用できるようになりましたKVM hypervisor。）

次の問題は、画面の解像度が800x600のままだったことです。 Windowsでは変更できません。 TianoCoreスプラッシュが表示されたら、マシンが起動したらすぐにEscを押すことで、1回限りの修正を行うことができます。これにより、UEFI設定が表示され、より高い解像度を強制できます。しかし、これは恒久的な修正ではありません。

私の仮想マシンはQXLをビデオデバイスとして指定していたため、WindowsにQXLドライバーをインストールする必要がありました。このページ virtIOドライバーを使用したWindows仮想マシンの作成 では、その方法について説明しています。短いバージョンは次のとおりです。ホストマシンに virtio-win iso をダウンロードします。これをVMにCD-ROMドライブとして追加します。次に、VMを起動し、CD-ROMの適切なフォルダに移動して、必要なすべてのVirtIOドライバをインストールします。 Windows 10のQXLビデオには、「qxldod」フォルダーに適切なドライバーがあります。

windows-10uefilinux-kvmp2v
2
Matt

QEMU/Libvirtは仮想ディスクを提供することを期待しています。QCOW2ファイルはパーティションではなくディスクである必要があります。あなたがしたことをすることにより、あなたは4つのqcow2ファイルを手に入れました、それぞれが単一のパーティションを持っています。あなたは以前の構造を壊しました、GRUBがあなたのシステムをもう起動できないのは驚くことではありません。

物理ドライブ全体を単一のQCOW2ファイルに変換してから、この仮想ドライブをVMに接続することをお勧めします。

GRUB EFIファイルをEFIパーティションから削除し（libguestfsツールを参照））、WindowsブートローダーがVMのUEFIによってロードされる必要があるため、ブートメニューを利用できるはずです。

1
Dylan

他の誰かがこの質問に出くわした場合、ネイティブのWindowsインストールをVMとして使用する別の方法があります。

  1. ディランの承認された回答に従って、デバイス全体をイメージします。
  2. 生ストレージからVMを実行します。

上記の＃2を管理しましたが、かなり複雑になる可能性があります。 LinuxとWindowsの両方が同じデバイスを共有する場合、それは非常に複雑になり、リスクになります。

さまざまな理由で追加の努力をするだけの価値があります。

  • すでにデュアルブートセットアップがあり、好きです。
  • ハードウェア上で直接ウィンドウを実行する必要があります。
    • ゲームのグラフィックパフォーマンス（および2x GPUなどでPCIパススルーを実行できるマザーボード/セットアップがない場合）。
    • 仮想化されたオーディオデバイスでは十分に機能しない、Skype for Businessなどの非常に機密性の高いオーディオアプリケーション。
  • VMの利便性を求めて、MS Officeなどのそれほど要求の少ない他のWindowsアプリを実行します。

多数の警告/回避策がありました：

  • ライセンスをハードウェアに結び付けているので、ウィンドウをアクティブ化したままにするための戦いがありました。マザーボード/ BIOSのシリアル番号、正確なCPUモデル、およびストレージデバイスのシリアル番号を追加するのに苦労しました。
  • Linux/Nautilus/GnomeファイルマネージャがWindowsパーティションを無視するようにudevルールを追加します。
  • パラノイア（心配なWindowsの更新がgrub/bootのセットアップに影響を与える可能性がある）のため、生のドライブ全体をVMと共有するだけではありませんでした。代わりに：
    • パーティションテーブル（GPT）とEFIパーティションをファイルに複製し、デバイスイメージファイルの偽の端を作成しました。
    • ループバックドライバーを使用して、クローンイメージをデバイスとして処理しました
    • Mdadmリニアセットアップを介してMD（マルチデバイス）ドライバーを使用し、必要なすべてのパーツをVMのハイブリッドイメージデバイスおよびrawデバイスとしてチェーンしました。例えば。 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 updateは、調整しなければならない余分なパーティティオンを投げました！ Windows 10 April Updateのインストール後に新しいパーティションが表示されます 。もう一度修正する必要がありました...

私は2番目のシステムでも同様の設定を使用しましたが、1つはLinux用、もう1つはWindows用の2つの別々のストレージデバイスを使用することで、私の生活をはるかに簡単にしました。

1
JPvRiel