- Quickemu は QEMU 用のラッパーで、実行するオペレーティングシステムを選ぶと、仮想マシン作成に必要な設定を自動で処理し、Windows、macOS、Linux VM を素早く作成・実行する
quickget は目的のオペレーティングシステムの アップストリーム OS イメージを自動ダウンロードして VM 設定ファイルを作成し、quickemu はハードウェアを検出して、そのコンピューターに合った構成で VM を実行する- 当初の目標は Linux ディストリビューションを素早くテストすることで、VM と設定は外付け USB ストレージやホームディレクトリなど任意の場所に置くことができ、実行に 昇格権限は不要
- 現在は macOS、Windows、ほとんどの BSD、FreeDOS、Haiku、KolibriOS、OpenIndiana、ReactOS など、約1000のオペレーティングシステムエディションをサポートする
- Linux と macOS ホストで動作し、SPICE、ファイル共有、QEMU Guest Agent、VirGL、USB パススルー、ポートフォワーディング、オーディオ、EFI と Legacy BIOS ブートなど、VM 利用に必要な機能を提供する
Quickemu が行うこと
- Quickemu は QEMU を包むラッパーで、仮想マシン作成時に必要な設定を自動で処理する
- ユーザーは実行するオペレーティングシステムだけを選べばよく、多くの設定オプションを自分で指定する必要はない
- 中核となるツールは2つ
quickget: 目的のオペレーティングシステムの アップストリーム OS を自動ダウンロードし、VM 設定ファイルを生成するquickemu: ホストハードウェアを列挙したうえで、そのコンピューターに合った最適構成で仮想マシンを実行する
プロジェクトの出発点と現在の範囲
- 当初の目標は Linux ディストリビューションのテストを素早く行えるようにすることだった
- VM と設定は、外付け USB ストレージやホームディレクトリのように任意の場所に保存できる
- 仮想マシンの実行には 昇格権限は不要
- 現在のサポート範囲は Linux ディストリビューションを超え、macOS、Windows、ほとんどの BSD、非 Linux オペレーティングシステムへ拡大している
- サポート例には FreeDOS、Haiku、KolibriOS、OpenIndiana、ReactOS などがある
サポートするオペレーティングシステムとホスト
- ホストは Linux と macOS をサポートする
- ゲストオペレーティングシステムには次が含まれる
- macOS Sequoia、Sonoma、Ventura、Monterey、Big Sur、Catalina、Mojave
- Windows 10 と 11、TPM 2.0 を含む
- Windows Server 2022、2019、2016
- Ubuntu とすべての公式 Ubuntu flavour
- ほとんどの BSD と複数の非 Linux オペレーティングシステム
- ARM64 ゲストをサポートし、aarch64 VM を実行できる
- ARM ホストではネイティブ実行
- x86_64 ホストではエミュレーション実行
- サポートするオペレーティングシステムエディション数は 約1000 に達する
VM 機能
- SPICE のフルサポートを提供し、ホスト/ゲスト間のクリップボード共有を含む
- ファイル共有方式は、ゲストオペレーティングシステムに応じて複数の方式をサポートする
- VirtIO-webdavd: Linux と Windows ゲスト向けファイル共有
- VirtIO-9p: Linux と macOS ゲスト向けファイル共有
- Samba: Linux、macOS、Windows ゲスト向けファイル共有で、ホストに
smbd がインストールされている必要がある
- QEMU Guest Agent をサポートし、標準の QMP コマンドでシステムレベルのエージェントにアクセスできる
- グラフィックスとデバイス機能として VirGL アクセラレーション、USB デバイスパススルー、スマートカードパススルーをサポートする
- ネットワークと入出力機能も含む
- ゲストへの自動 SSH ポートフォワーディング
- ネットワークポートフォワーディング
- フルデュプレックスオーディオ
- 点字サポート
- SecureBoot ありまたはなしの EFI ブート
- Legacy BIOS ブート
クイックスタートの流れ
quickget nixos unstable minimal
quickemu で quickget が作成した設定ファイルを使って VM を起動する
quickemu --vm nixos-unstable-minimal.conf
- 引数なしで
quickget を実行すると、サポートされるすべてのオペレーティングシステム一覧を確認できる
ドキュメントと参考資料
- Wiki は開始方法と高度な設定および使い方を扱う
1件のコメント
Hacker News の意見
以前、複数の VM ホストとローカル VM を大量に管理していたときは、いつも使っていた。
VM に関する基本用語はある程度知っておく必要があるが、機能とパワーが詰め込まれた昔ながらの GUI をかなり思い出す。
要件が単純だったり、VM 周りにあまり慣れていないなら、Gnome Boxes が同じバックエンドを使いつつ、すっきりした GUI を提供している。単純なぶん柔軟性は下がるが、後で Boxes に露出していない設定を調整する必要が出た場合に、Gnome Boxes の VM を virt-manager で開けるのが良い。
SSH でリモートシステム上で実行すると、Fedora のローカル Wayland セッションに QEMU コンソールを「X フォワーディング」してくれる。
最初はヘッドレスモードで動くのだと思っていたので、ウィンドウが出てきてかなり驚いた :)
設定が、その設定対象のソフトウェアから分離されていたらどうなるか想像してしまう。各 UI プログラムが車輪の再発明をしたやり方を覚える代わりに、好みの設定マネージャーを選んで使えるはずだ。
現時点で最も近いのはテキスト設定ファイルだ。これを使うすべてのプログラムは、特定の言語と保存場所を選ばなければならない。
最近よく考えているアイデアは、設定の仲介レイヤーだ。ユーザーに見える設定 UI には好みの言語/形式を使い、そのデータを単一の真実の供給源として、ソフトウェアが読む設定ファイルを生成する方式だ。
設定ファイルベースの開始/停止やシリアルコンソールアクセスのような便利な管理機能もあるが、こうしたものはシェルスクリプトで自作するのも非常に簡単だ。libvirt のストレージ処理はひどく冗長で複雑なのに、thin LV や ZFS すらまともに扱えない。
標準的なエンタープライズ流のやり方で動かしたい、かつ QEMU やシェルのような基礎ソフトウェアを学ぶ気がない、あるいは libvirt の中途半端な機能がどうしても必要、というのでなければ、KVM 上で QEMU を直接使い、自前のスクリプトを使うほうを勧める。いまいちな Python ラッパーより QEMU を多く学べるし、システムの制御権も大きくなる。
また IBM/Red Hat は virt-manager を新しい Web インターフェースである Copilot のほうへ押しやっており、事実上廃止したように見える。
Quickemu は、大きく複雑な UI を学ぶのに時間を使わず、例を少し見たあとで新しい VM をすぐ起動できるので、より興味深い。
このツールはインターネットから任意のファイルをダウンロードし、そのチェックサムをさらにインターネット上の別の任意のファイルと照合する[2]。
最善のセキュリティ慣行ではない。正しい方法は、ディストリビューション開発者の GPG キーをリポジトリにコミットしておき、すべてのファイルをそのキーで検証することだ。
とはいえ、このプロジェクトが複数の OS を起動させるために QEMU に渡す正しいフラグを突き止めた努力を貶めるつもりはない。
[1] https://news.ycombinator.com/item?id=28797129
[2] https://github.com/quickemu-project/quickemu/blob/0c8e1a5205...
そのうえ、ほとんどの人がやらないハッシュ一致検証まで追加で実施している。
FTP の時代にはチェックサムと GPG は必須だった。HTTP/TCP では再試行とチェックサム処理は TCP が行うので GPG の必要性はむしろ大きくなるが、中間者攻撃のためにどちらも依然として必要だった。
でも HTTPS なら、それでもなぜ重要なのだろう？HTTPS が両方の検証と署名確認を代替してくれるのではないのか。
今年 Hacker News で関心を集めたことがきっかけになって、誰かが Linux 用の署名検証を実装してくれるといい。
0. https://mac.getutm.app/
https://docs.getutm.app/installation/ios/
最近の Alma Linux の例は次のとおり。
$ virt-install --name alma9 --memory 1536 --vcpus 1 --disk path=$PWD/alma9.img,size=20 --cdrom alma9.iso --unattendedコーヒーを一杯飲んで戻ってくると、インストール済みの Alma Linux VM が動いている。対応 OS の一覧は libvirt のバージョンによって変わり、次で確認する
$ osinfo-query osFedora 39 のディスクイメージが必要なら virt-builder もある
$ virt-builder fedora-39後で
virt-install --importで libvirt に取り込めるvirt-install は ISO を自動でダウンロードするのか？ 試すとこういうメッセージが出る
$ virt-install --name alma9 --memory 1536 --vcpus 1 --disk path=$PWD/alma9.img,size=20 --cdrom alma9.iso --unattendedERROR Validating install media 'alma9.iso' failed: Must specify storage creation parameters for non-existent path '/home/foo/alma9.iso'.この結果がどうなるのかは明確ではない。ホスト名は何になり、ディスクはどうパーティション分割され、どのパッケージがインストールされ、タイムゾーンやキーボード配列は何に設定されるのか、などが気になる
これを行うには libosinfo-bin をインストールする必要があった
こうしたツールの利便性は素晴らしいが、主要スクリプト 2 本を合わせると Bash 5000 行 ほどある
実行前に確認したいが、Bash 5000 行は読みたくない
説得力があるかは分からないが、実行前に Bash スクリプトを読んでみたところ、かなりよく構造化されていた。機能は関数にうまく分けられており、変数名も妥当で、有用なコメントがあり、奇妙な制御フローや間接呼び出しもなく、難解なコマンドの使用も最小限だった。これまで見たシェルスクリプトの中でもかなり読みやすい部類に入る
このスクリプトが実際にやっていることを考えると、コードが比較的まっすぐなのも納得できる。核心は QEMU を起動するコマンドを 1 つ実行することだ。残りのコードは、そのコマンドにどの引数を渡すかをローカルシステムで確認したり、必要ならいくつかのファイルをダウンロードしたりする処理だ
盲目的に実行すべきという意味ではないが、実行するソフトウェアを選ぶ基準は、普通はソースコードに慣れているかどうかには依存しない
“You are a linux guru, and you have extensive experience with bash and all forms of unix/linux. I am going to be pasting a large amount of code in a little bit at a time. Every time I paste code and send it to you, you are going to add it to the previous code and ask me if I am done. When I am done we are going to talk about the code, and you are going to help me break it down and understand what is going on. If you understand you will ask me to start sending code, otherwise ask me any questions before you ask for the code.”
もっと短いコード、それでもプロンプト上限を超える 1000 行未満のコードではこの方法を使ってみたことがあり、かなりうまく機能した。最近の ChatGPT が怠け気味なのは認めるし、時には怠けずに要求した出力全体を出すよう明示する必要があるが、全体としてコードの説明はかなりうまい
「多くの目があれば、すべてのバグは浅い」という言葉は、一部のユーザーにとって思考停止を招く決まり文句のように見える。公開されていてレビュー可能だから大丈夫だろうと考え、あらゆるものを検査するコード監査者の集団が巡回しているようなイメージを抱くが、実際には善意より悪意のほうを予想してしまう
Windows 方面には、何十年にもわたってチューニングユーティリティが絶えず存在してきた。「大企業」の開発者にはシステム性能を限界まで引き出す動機がなく、高速化設定やレジストリ調整の裏に、誰にとっても有用な簡単なオプションを残しているのだと信じる人々を引きつける。時々見かける TronScript を思い出すが、歴史と参加度を見る限り、直感的な健全性チェックは通過しそうなので良いものだと思う一方で、自動化という名目で詳細を隠し、ユーザーの代わりに良い判断をしてくれることを期待させる。掘り下げて何がなぜ起きているのかを調べて学ぶこともできるが、多くの人にとっては実質的にバイナリと変わらない
幸いなのは、こうしたツールの大半は利用者層が限られており、侵害する価値がそれほど大きくないことだ。特定のブランドが十分に広く使われるようになると、2017 年にバックドアを仕込まれた Piriform の CCleaner のような状況が起こり得る
面白そうだが、Ubuntu でたまに VirtualBox を使って Windows 11 だけを動かしている人にとって、どんな利点があるのか教えてもらえるだろうか？
Linux では Incus/LXD を強くおすすめする。VM の実行はこれだけ簡単だ
実行後のシェルアクセスは次のようにする
Incus/LXD はシステムコンテナにも対応している
好きだがあまり言及されないものとして systemd-nspawn がある。
docker create --name ubuntu ubuntu:22.04を実行し、docker export ubuntuで任意の Docker イメージから tar を作るその後
/var/lib/machines/ubuntuに展開すればよい。systemd が入っているイメージを選ぶか、コンテナ内に systemd をインストールする必要がある。最後にmachinectl start ubuntuとmachinectl shell ubuntuで入るsystemd-nspawn は非常にシンプルで軽量で、実際の Linux マシンをかなりうまくエミュレートする。systemd ベースの任意のルートパーティションを持ってきて systemd-nspawn で起動すれば、そのまま動作する
VM を単純に実行する場合と比較した 性能変化の数値 はある？ 普段 Linux ホスト上で Linux ゲストを動かしているが、ゲスト性能にはよく失望する
VM 体験をチューニングする調査をしたことがないので、どれくらい取りこぼしているのか気になる。5% 速いのか？ 100% なのか？
Arm、つまり Apple Silicon でネイティブに動く？ 最新の macOS バージョンはどうか？ グラフィックアクセラレーションはある？ ネットワークはどう処理される？
Proxmox と何が違うのか、ここで行っている最適化を自分の Proxmox 環境 に手動で再現できるのか気になる
Quickemu は主にデスクトップ用途を狙ったものに見える