２．旧PCのCドライブのイメージ吸い出し
普通のPCはCドライブにOSを入れていると思いますが、このCドライブをまるごとイメージ化します。
旧PCはイメージの吸い出しで使うのは、LinuxのLive版をインストールしたUSBメモリ。
Linuxのディストリビューションはどれでもいいですが、今回はZORIN OSにしました。
Live版ZORIN OSを起動し、
左下のボタンから[端末]を選択。
各ディスクの確認をします。
$ sudo fdisk -l
(略)
ディスク /dev/sdc: 232.89 GiB, 250059350016 バイト, 488397168 セクタ
Disk model: CT250MX500SSD1
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: 0524FBBE-95C3-11F0-BCBB-B827EBCF3D67
(略)
Windowsが入っているドライブはMicrosoftとか名前が入っていたり、パーティションが別れているのでわかりやすく、私の環境では/dev/sdcが該当することがわかります。
あとはこれをddコマンドでイメージにするだけ。ファイルの吐き出し先は外付けUSB接続の3TBドライブとします。
接続した3TBは/media/zorin配下にマウントされているため、そちらをddコマンドのoutputに指定。
読み書きの速度はオプションで指定しないと激遅になるため、適当に10MBとします。
$ sudo dd if=/dev/sdc of=/media/zorin/3TB/win10.dd bs=10M
書き出しが完了したらLive版ZORIN OSはシャットダウンでOK。
※ちなみに6項で触れますが、この作業はもう一回やりました。
３．新PCへのZORIN OSのインストール
2項で使ったLive版ZORIN OSを使ってインストールをします。
USBメモリを指して起動、デスクトップにあるインストールボタンを押すだけであとは適当に次へを押せば完了するため、省略。
４．仮想環境の構築
7年ぐらい前はIntelでしたが、今回はRyzenなので、やり方が少し異なります。
４−２．GPUパススルーのための情報収集
前回と同様、グラボのデバイス情報を取得します。
$cd ~/
$ vi aaa
#!/bin/bash
shopt -s nullglob
for d in /sys/kernel/iommu_groups/*/devices/*; do
n=${d#*/iommu_groups/*}; n=${n%%/*}
printf 'IOMMU Group %s ' "$n"
lspci -nns "${d##*/}"
done;
$ sudo chmod 755 aaa
$ ./aaa
(略)
IOMMU Group 13 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2f04] (rev a1)
IOMMU Group 13 01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:2f80](rev a1)
(略)
赤字の部分が後の工程で絡んでくるのでメモっておきます。
前回はlibvirtの最新パッケージの更新として
ppa:jacob/virtualisation
を追加で設定していましたが、現在は配信停止されているようなので、素直にaptでインストールします。
$ sudo apt install -y libvirt-daemon-system ovmf libvirt-clients bridge-utils virt-manager qemu-kvm qemu-utils qemu-efi
多分上記のもので大丈夫だと思いますが、ダメだったら「libvirt-bin」「libvirt-dev」「libvirt0」辺りも入れてください。
libvirtの有効化を確認をします。
$ sudo systemctl is-active libvirtd
active
OKですね。
QEMUの仮想化が問題ないか確認します。
$ virt-host-validate
QEMU: Checking for hardware virtualization : PASS
QEMU: Checking if device /dev/kvm exists : PASS
QEMU: Checking if device /dev/kvm is accessible : PASS
QEMU: Checking if device /dev/vhost-net exists : PASS
QEMU: Checking if device /dev/net/tun exists : PASS
QEMU: Checking for cgroup 'cpu' controller support : PASS
QEMU: Checking for cgroup 'cpuacct' controller support : PASS
QEMU: Checking for cgroup 'cpuset' controller support : PASS
QEMU: Checking for cgroup 'memory' controller support : PASS
QEMU: Checking for cgroup 'devices' controller support : WARN (Enable 'devices' in kernel Kconfig file or mount/enable cgroup controller in your system)
QEMU: Checking for cgroup 'blkio' controller support : PASS
QEMU: Checking for device assignment IOMMU support : PASS
QEMU: Checking if IOMMU is enabled by kernel : PASS
QEMU: Checking for secure guest support : WARN (Unknown if this platform has Secure Guest support)
(略)
LXC: Checking for cgroup 'devices' controller support : FAIL (Enable 'devices' in kernel Kconfig file or mount/enable cgroup controller in your system)
LXC: Checking for cgroup 'freezer' controller support : FAIL (Enable 'freezer' in kernel Kconfig file or mount/enable cgroup controller in your system)
何やらWARNとFAILが…
higmasan.com
unix.stackexchange.com
このあたりサイトを見ると、どうやら
intel_iommu=on
systemd.unified_cgroup_hierarchy=0
をカーネルコマンドラインパラメータに記載し、
grub2-mkconfig
を使って設定を変更すればいいといったことが書かれている。
しかし、私が使っているのはAMDのCPUであり、intel iommu=onを書く必要はまずない。
そしてZORIN OSにはgrub2-mkconfigのコマンドはない(grub-mkconfigはある。多分ベースになっているUbuntuも同様？)
discussion.fedoraproject.org
↑の記載を読むと、どうもOSがcgroup2を使っているならfreezeを使う必要はないとのことが書かれている(必要なのはcgroup1とのこと)
gihyo.jp
cgroupはプロセスをグループ化して制限をかけられる技術…とのことだけど、いまいち不明。
cgroupのv1とv2を調べる方法は以下のサイトを参考とし、少なくともZorin OS17.3に関してはcgroup v2が動いている模様。
kazuhira-r.hatenablog.com
$ stat -fc %T /sys/fs/cgroup/
cgroup2fs
cgroup2fsなので、cgroup2みたいですね。
freezeはいらんと言っているページを翻訳すると、
同じエラーに遭遇し、冷凍庫を使用する必要性を調べた結果、cgroup2 を使用する場合には冷凍庫は必要ないことがわかりました。もし systemd.unified_cgroup_hierarchy=0 GRUB のコマンド ラインで追加されると、システムは非推奨の cgroups1 を使用することになります。
走ろうとした時に気づいた podman、そして私はcgroup1 を使用していることを助言する警告を得ました。行を削除すると、メッセージが消えました。
私の理解では、FAIL メッセージは次のとおりです virt-host-validate cgroup_freezer は無効にする必要があるため、cgroup2 を使用するシステムには関係ありません
これはWARNとFAILは無視していいのでは…？というのが今の所の結論。
実際のところこの後にQEMUでのVM起動とGPUパススルーは成功したので、(性能は劣化しているかもしれませんが)とりあえず無視します。
４−４．libvirtdとvirtlogdが動いているかsystemctlで確認
$ sudo systemctl status libvirtd
● libvirtd.service - Virtualization daemon
Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2025-09-16 16:43:22 JST; 9min ago
$ sudo systemctl status virtlogd
○ virtlogd.service - Virtual machine log manager
Loaded: loaded (/lib/systemd/system/virtlogd.service; indirect; vendor preset: enabled)
Active: inactive (dead)
TriggeredBy: ● virtlogd.socket
● virtlogd-admin.socket
Docs: man:virtlogd(8)
https://libvirt.org
libvirtdの方はすでに起動しており、自動で立ち上がるようになっていると思われるけど、念の為enableは実行しておきます。
virtlogdはinactive (dead)だったので、起動した上でenable実行。
$ sudo systemctl enable libvirtd
$ sudo systemctl enable virtlogd
$ sudo systemctl start virtlogd
$ sudo systemctl status virtlogd
● virtlogd.service - Virtual machine log manager
Loaded: loaded (/lib/systemd/system/virtlogd.service; indirect; vendor preset: enabled)
Active: active (running) since Sat 2025-09-20 00:15:21 JST; 4min 14s ago
TriggeredBy: ● virtlogd-admin.socket
● virtlogd.socket
Docs: man:virtlogd(8)
https://libvirt.org
Main PID: 4741 (virtlogd)
Tasks: 1 (limit: 74024)
Memory: 2.2M
CPU: 5ms
CGroup: /system.slice/virtlogd.service
└─4741 /usr/sbin/virtlogd
６．仮想Windows10が起動しない件と解決策
色々試すと、ファームウェアで「BIOS」を選択するとWindows10起動し、「UEFI」を選択すると起動しませんでした。
これはファイル形式がrawでもqcow2でも同様。選択したUEFIがセキュアブートに対応してないから？と思いましたが、どうも根本的に何かが違うということでさらに調べたところ、どうやら吸い出した際のWindows10のディスクがMBR形式であり、それだとダメで、GPT形式になっている必要がある模様。
なので、吸い出し元の旧PCでMBR→GPTに変換します。
実施方法は別に書き起こしました。
engetu21.hatenablog.com
これをZORIN OSのLive版にてddコマンドで2項と同じようにrawファイルとして書き出し、新PCにファイルコピーします。
コピー後、rawファイルはQEMUのディスクイメージ(qcow2)に変換します。ファームウェアが「UEFI」でrawファイルのWIndowsが起動できるのかは謎ですが(試さなかった)、ディスク容量を拡張する必要があるので、このタイミングで変換します(拡張は形式変えなくてもいけるかも？とりあえず変換します)。
参考：
docs.openstack.org
rawファイル→qcow2ファイルへの変換コマンドは以下の通り。
$ qemu-img convert -f raw -O qcow2 win10-2.raw win10-2.qcow2
続けて、先程触れたとおり、変換して作った「win10-2.qcow2」ファイルの容量を拡張します。
吸い出したイメージファイルは、上限が吸い出し元の最大ディスク容量分しかない、かつすでに容量カツカツで使っていたため、windows11にアップグレードするために容量を増やしておく必要があります。
とりあえず200GB追加します。
$ sudo qemu-img resize win10-2.qcow2 +200G
Image resized.
VMは作り直すか、ディスク追加で先程作ったqcow2ファイルを指定して追加。
[SATAディスク2]が新たに追加されます。この際、元々あった[SATAディスク1]を右クリックから削除します。
すると[SATAディスク2]が[SATAディスク1]に変更されます。(つまりディスクの入れ替えができる)
この状態で再度VMを起動します。
無事起動！
システムの詳細情報を見てみると・・・
すでにグラボが認識されています。デバイスマネージャーを見ても同様。
以前はvendor id偽装(【Linux Mint】【QEMU/KVM】KVMによる仮想化Win10へのGPUパススルー設定 - 技術メモ)という面倒な作業を実施しており、というのもTeslaといったGPGPU専用グラボ以外はGPUパススルーができなかったからですが、どうやらAI生成やら諸々の流れでどうやらそういった制約は解除された模様(どこかのページでベータ版とかなんとか書いてあったような)。
８．仮想Windows10をWindows11へアップグレード
システム画面でWindows11へのアップグレードのメニューが出てくればいいんですが、出てこないのでアップグレードアプリから実行します。
キャプチャは忘れましたが、正常性診断のツールでWindows11へのアップグレード要件を満たしていることは確認済み。
一応、Windows10のイメージファイル(qcow2ファイル)はバックアップをとってから実行します。VMはこういうときに便利。
www.microsoft.com
から「Windows 11 インストール アシスタント」をダウンロードし、実行。
ひたすら待ちます。
無事、Windows11化完了です。
９．グラボ経由でのモニタ表示
一旦、WindowsVMをシャットダウンし、USBパススルーによる物理キーボードとマウスの接続、及び「ディスプレイSpice」と「ビデオQXL」を削除し、グラボでの画面描写に切り替えます。
これにより、グラボを経由したモニタ表示とホストOSから独立したキーボード/マウスによる操作ができるようになります。
無論、「ディスプレイSpice」と「ビデオQXL」を削除せず、ホストOS上で表示しながら操作も可能ですが、もしこのVM環境でゲームをやる場合、GPUを利用した描写ができないため、ゲームはろくに動かないと思われます。
ただ、生成AIを実行する場合に対してはそうではないと思われ、生成AIアプリがグラボを認識してくれれば、画面描写はVMの素の機能、生成AIアプリはグラボを利用と分けられるかもしれません(←やってみました。どうやらできる模様)。
VMを2つ設け、①ゲーム用、②それ以外と分け、お互い同一のWindows11のイメージディスクを指しつつも、必ず同時実行をしないようにしつつ(これは自分で気をつけるしかない)、ゲームしたいときはグラボから画像出力する①、それ以外は②、という風に運用するのも面白いかもしれません。
