Linuxを学ぶ歩みでは触れなかった外伝ストーリー！QEMU/KVMスキルツリー。
現時点で、GNU/Linuxシステムによくある仮想化ソフトウェアには：
- QEMU/KVM、Virt ManagerまたはGNOME Boxesと組み合わせて管理
- Oracle VirtualBox
- VMware
- Xen
なぜ本サイトの「仮想マシンとコンテナ技術」分類の記事で扱う仮想マシンソフトウェアは、ほとんどQEMU/KVMなのか？（少なくとも今のところ）これは私のQEMU/KVMへの沈迷から話さなければならない。
不肖ながら、Linux仮想化に関する理解もまだ一瓢飲の程度にすぎない。
1. グラタン風スパゲッティとQEMU/KVM#
今までQEMU/KVM仮想マシンの研究に熱中している理由は、最初にLinuxへ移行したかったが、Windows機能へのアクセスを失うことを心配していたからだ。
2022年以前は、まだ邪教めいた自由ソフトウェアイデオロギーに触れていなかったので、私は当然Windowsを手放せなかった。Wineの存在を知っていても、必要な時にソフトウェアを動かせるよう、すぐWindows環境を作れる仮想マシンが欲しかった。
（後知恵：二年後に資工系でC#プログラムを学ぶことになり、仮想マシンが命を救い、Visual Studioをインストールして課題を完成できるとは思わなかった。）
それ以前にも仮想マシン操作の経験は少しあったが、実は背後の原理はあまり理解しておらず、VirtualBoxとVmwareは直感的で使いやすいと感じていただけだった！システムはさっとインストールできた。QEMU/KVMは私にとって未知の領域だった。
私はおぼろげに、仮想マシン最大の弱点はグラフィック処理能力だと理解していた。そこで大学二年の時（2020年）からGPUパススルー技術の研究を始めた。
屏東大学の学生寮付属の学食で、私はグラタン風スパゲッティを注文し、座ってスマートフォンを取り出し、「為了可能的聲音」、「CT Wang」、「如何在Linux打LOL」、「鳥哥」などの人が書いた文章を読みながら、GPUパススルーの方法を研究し始めた。
同じ時期に、実機へHackintoshをインストールすることも試した。記事を読み、寮に戻ってテストしたら本当に成功した！ああ、でもサウンドカードkextを解決できなかったので、すぐ諦めたㄌ
店が提供する小さな碗に料理が盛られ、スパゲッティはアルミホイルの真ん中に包まれ、上には熱々のグラタン生地が覆っていた。フォークで突き破ると、とろみをまとったトマト麺と生地が巻き付き、口に入れるとサクサクで甘酸っぱく、本当に美味しかった。
マンマミーア、ネット記事に何が書いてあるのかまったくわからない。IOMMU、VFIO、nouveauブラックリストって何のこっちゃ！？なぜ誰も彼もGPUパススルーの紹介を論文みたいに書くのか。読んでいるうちに麺も食べ終わったので、やめて寝た！
ゆっくり2022年になって、私は初めてUbuntuでGPUパススルーに成功した。突然悟ったわけではなく、試行錯誤を重ねて成功しただけだ。なにせ当時はvimすら使えなかった時期だった。
初めて何かを成し遂げた喜びはいつも盛大で、踊り出しそうなほどだった。だから私はGPUパススルー手順を細かく旧「Ivonの実験室」ブログに書いた。この文章は後にこのブログへ移動した：Ubuntu Nvidia GPU直通教學
その後、大distro-hopping時代に入ったが、QEMU/KVMを忘れることはなかった。これは必ず毎回システムを入れる時にインストールするソフトウェアだ。
異なるLinuxディストリビューションで似た手順を繰り返し、GPUパススルーを何度もやるうちに、手順への熟練度もかなり高まった。背後の論理関係も少しずつ探り出した。
Virt ManagerにはGUIが使えるのに、なぜ多くの人がコマンドラインのvirt-installで仮想マシンを追加し、さらにvirshコマンドの使い方を重点的に紹介するのか、私にはわからない。もちろん、それは各人の関心の向きが違うだけだ。なにせ私は仮想マシンで遊びたいのであって、本当にサーバーを管理したいわけではない。
2022年、BlissOSで遊んでいる時についでにvirglrendererの準仮想化GPUアクセラレーション技術を学んだ。
2023年、Looking Glassを使って仮想マシン画面を取得し、外部モニターを置き換える使い方を覚えた。ついでにゲームによるQEMU/KVM仮想マシン検知を回避する技巧も学んだ。
GPUパススルー以外にも、VirtIO-FS、容量拡張、リモート仮想マシンデスクトップの使い方など、多くのLibvirt関連技術もついでに学んだ。これはまさに学びに終わりなしと言える。
今では、すでに四年研究している。断続的にようやくLibvirtとQEMU/KVMの緩く複雑な関係を理解してきた。私のような学習速度なら、資工系の授業を履修していたらとっくに100回落とされている。
2. QEMU/KVMを使う利点#
なぜQEMU/KVMをデスクトップ版Linuxの仮想化案として語る人は少ないのか？ユーザーはサーバー運用保守エンジニアが中心のようで、そうでなければファームウェアを書くエンジニアがコマンドラインでQEMUを走らせている。ではQEMU/KVM仮想マシンを使うことには、いったいどんな優勢があるのか？
RedHat公式サイトの説明を参考にすれば、Vmwareと比べて、コスト、拡張性、オープンソース、柔軟性がQEMU/KVMの利点だ。
しかし私は、柔軟性こそ最大の欠点でもあると思う。
多くの初心者デスクトップLinuxユーザーはVirtualboxやVmwareのような仮想化案を好むようだ。その理由は理解しやすい。参考資料が比較的多く、クロスプラットフォームで、始めやすいからだ。
それに比べて、QEMU/KVMの案は非常に緩い組み合わせであり、マーケティングには不利だ。QEMU/KVMパッケージ以外にも、Libvirt、virsh、Virt Manager、Virt Viewer、OVMF、VirtIO、swtpmなどのサービスをインストールして、初めて組み合わせられる。そして最後まで遊ぶと、Virt Managerは単なるフロントエンドにすぎないとわかる！背後で本当に動いている仮想マシンはLibvirtとQEMU/KVMだ。さらにひどいことに、GUIはLibvirtのすべての機能を管理できない。時には仮想マシンXMLを手動編集したり、コマンドを打ったりしなければならない。これはかなり不親切だ。
もしかすると、本当にQEMU/KVM機能を必要とするユーザーは、皆そのままProxmox VEを入れているのではないか？あれのWeb管理インターフェイスはとても使いやすい！
しかしデスクトップLinux中心の使用環境に戻ると、本当に「自由ソフトウェア」の解決策が必要で、なおかつ「PCI Passthrough」機能を満たしたいなら、前の二つの仮想マシンソフトウェアは同時には満たせない。
さらにQEMU/KVMは多くのツールから管理できる。たとえばLibvirt、virsh、Virt Manager、Cockpit、oVirt、GNOME Boxesなどだ。
これこそQEMU/KVMの利点である。
なぜ私の記事では「QEMU/KVM」と強調し、KVMだけと書かないのか。それはソフトウェア開発者にも同等の重視を受けてほしいからだ。KVMはカーネルモジュールにすぎず、QEMUとの組み合わせがなければ何者でもない。確かに、市場にはQEMUに依存せずKVMを走らせる仮想マシンソフトウェアもある。たとえばAmazon Firecrackerだ。しかし現時点では、QEMUとKVMを組み合わせることが依然として主流のやり方である。
3. 現在QEMU/KVMを走らせる構成#
学んだことは限られており、将来構成を変える可能性がある。
現在の使い方は混合型だ。私はLinuxをデスクトップシステムとして使い、外出時にはSSHと内網穿透ソフトウェアでリモートアクセスし、Linuxをサーバーとして使う。
PCにはIntel内蔵GPUがあるので、Nvidia GPUパススルー時にもLinuxはデスクトップを使える。大部分の時間、ネットを見るだけならNvidia GPUはあまり必要ない。大型ゲームを遊ぶ時はWindows仮想マシンの中に突っ込む。
QEMU/KVMを走らせるPCは、CPUとRAMが大きければ大きいほどよい。
Linuxディストリビューションは安定リリースのもの、つまりUbuntu LTSを選んだ。Arch Linuxのような不安定な環境で動かしたくない。それは仮想マシンの中でテストすればよい。外部の基盤インフラはここまで放蕩であってはならない。
仮想マシン容量の問題については、かなり愚直に仮想マシンqcow2ファイルを第二のハードディスクへ保存するしかない（だからdistro-hoppingを生き延びられる）。容量が必要な時に手動でqemu-nbdをマウントして調整する。LVMを学んだ後は、こんな愚かな方法は使わなくなるはずだ。その時にはRAIDも学ばなければならない。
今はGPUを使って何らかのAI演算を走らせる必要がある時、直接実機システムにPythonパッケージをインストールする過去のやり方の代わりに、仮想マシンで走らせている。こうした隔離環境はDockerよりも徹底している。
Nvidiaグラフィックカードを仮想マシンの中に閉じ込めている理由はもう一つある：KDE 5 X11とNvidiaドライバーの組み合わせは画面 tearing が起きやすい。ならばいっそ出てこないで、Intelに画面表示を担当させればよい。
最後に、私はずっと考えている。いつかいっそUbuntuをProxmox VEに替えたほうがいいのではないか？
うんうん、やめておこう。私はやはり実体のデスクトップLinuxに存在してほしい。永遠に仮想の機械の中で生きるのではなく。
