BoxesがVirt-managerに勝る場面とは?
深夜2時、新しくインストールしたパッケージが原因でステージングサーバーにエラーが出た。クリーンな環境でさっとテストしたいのに、ホームラボのProxmoxはバックアップ中で、12個のVMとコンテナがI/Oを使い切っている。virt-managerを開いてみると、ネットワークブリッジの設定、ストレージプールの構成、ファームウェアの選択……VMを1つ作るだけで15分かかる。今はそんな時間はない。
GNOME Boxesはまさにその問題を解決してくれる。libvirtもQEMUも知らなくても、3クリックでVMが起動できる。
3つのツール、3つの異なる用途
Boxes、virt-manager、VirtualBoxの3つはいずれもVMを作れる。ただし対象ユーザーはまったく異なり、間違ったツールを選ぶのはそのツールが悪いのではなく、自分のユースケースに合っていないだけだ:
GNOME Boxes
- 対象ユーザー:開発者、手軽にVMを使いたいデスクトップユーザー
- 実際のバックエンド:QEMU/KVM(裏で動いている)
- UI:3ステップのウィザード、設定不要
- 高度な設定:なし — これが長所でもあり、制限でもある
virt-manager
- 対象ユーザー:システム管理者、KVM/libvirtに慣れた人
- バックエンド:libvirt(QEMU/KVMを管理)
- UI:豊富なオプション — ネットワーク、ストレージプール、CPUトポロジー、PCIパススルー
- 高度な設定:あり — ブリッジネットワーク、複数ディスク、スナップショット
VirtualBox
- 対象ユーザー:クロスプラットフォーム(Windows/Macでも使う必要がある場合)
- バックエンド:独自ハイパーバイザー、KVMを使わない
- UI:使い慣れたインターフェース、豊富なオプション
- 高度な設定:あり、ただしパフォーマンスはQEMU/KVMより20〜30%程度劣ることが多い
各ツールのメリット・デメリット分析
GNOME Boxes — シンプルすぎて……時に不満も
最大の強みはzero configurationだ。インストール後、ISOをセットして数分待つだけでVMが動く。BoxesはディスクイメージとRAM(デフォルトでホストの約1/4、最低1GB)を自動で割り当て、ブリッジネットワークとは何かを聞いてくることもない。
しかし、そのシンプルさが制限にもなる。実際に何度もこう思った:
- VMに2枚目のディスクを追加したい — UIでは不可能
- ブリッジネットワークを設定してVMにLAN上の独自IPを割り当てたい — 直接サポートなし
- テスト前にVMのスナップショットを取りたい — Boxesにはこの機能がない
- 物理デバイスのUSBパススルー — virt-managerかQEMU CLIが必要
まとめると:Boxesはクイックテストに向いているが、長期的なVM管理には不向きだ。
virt-manager — 強力だが習得コストが高い
virt-managerはKVM/QEMUのフルパワーをGUIで操作できる。スナップショット、ブリッジネットワーク、PCIパススルー — すべて対応している。ただし、最初のVMを作るにはストレージプールとは何か、NATとブリッジの違い、libvirtdがどこで動いているかを理解する必要がある。初心者にとって、Ubuntuを試すだけでこれだけ多くの概念を覚えるのは負担が大きい。
VirtualBox — 馴染みはあるがLinuxでは遅い
VirtualBoxの本当の利点は1つだけ:同じVMファイルをWindows、Mac、Linuxで共通して使えること。それが唯一の選ぶ理由だ。KVMを使わないためQEMUよりパフォーマンスが明らかに劣り、I/Oベンチマークでは20〜30%の差が出ることが多く、CPU負荷の高いワークロードではさらに差が開く。純粋なLinux環境でVirtualBoxを選ぶ理由はない。
Rule of thumb:どのツールを選ぶか?
3つのツールを数年使い続けて、自分が適用しているパターンはこうだ:
- 新しいOSの素早いテスト、一時的な隔離環境 → Boxes(ゼロからVMが起動するまで5分)
- 特定のネットワーク設定、スナップショット、複数ディスクが必要な開発環境 → virt-manager
- 本番VM、クラスター、自動バックアップ → ProxmoxまたはLibvirt/virsh
- クロスプラットフォーム — 同じVMをWindowsでも使う必要がある → VirtualBox
GNOME Boxesのインストール
Ubuntu / Debian
sudo apt update
sudo apt install gnome-boxes
Fedora(GNOME Workstationを使っている場合は通常インストール済み)
sudo dnf install gnome-boxes
Arch Linux
sudo pacman -S gnome-boxes
インストール後、KVMがカーネルにロードされているか確認する:
lsmod | grep kvm
# 期待される出力:
# kvm_intel xxx 0 (Intel)
# kvm xxx 1 kvm_intel
# AMDのCPUの場合はkvm_amd
出力が見えない?BIOSでIntel VT-xまたはAMD-Vを有効にしよう。KVMなしでもBoxesは動くが、極端に遅い — ソフトウェアエミュレーションはワークロードによってはKVMより5〜10倍遅くなることがある。
GNOME Boxesで最初の仮想マシンを作成する
OSを自動ダウンロード(最速の方法)
Boxesを開く → 左上の+ボタンをクリック → 「Download an OS」を選択。BoxesにはUbuntu、Fedora、Debian、openSUSEなどのリストが用意されている。選択してDownloadをクリックし、ダウンロードが完了するとVMが自動的に作成されて起動する。
既存のISOを使う
- +をクリック → 「Use a file」を選択
- マシンからISOファイルを選択
- BoxesがOSを自動検出し、VM名を自動入力
- RAMとディスクの設定を確認 — このステップで変更可能
- 「Create」をクリック — VMがすぐにインストーラーで起動する
作成後にVMの設定を調整する
VMにカーソルを合わせる → メニュー⋮ → 「Properties」を選択。ここでRAM、ディスクサイズ、3Dアクセラレーションを変更できる。
長期利用のための実践的なヒント
VMのディスクファイルを探す
Boxesはすべての仮想マシンをqcow2形式で保存する:
ls -lh ~/.local/share/gnome-boxes/images/
# ubuntu-24.04.qcow2 8.5G
# fedora-40.qcow2 12G
このqcow2ファイルはvirt-managerにインポートしたり、より高度な機能が必要になったときにQEMUで直接使ったりできる。VMがBoxesに縛られない — これは意外と見落とされがちな利点だ。
VM作成後のディスクサイズ拡張(BoxesにはUIがない)
# 1. まずVMをシャットダウンする
# 2. qcow2ファイルをリサイズ
qemu-img resize ~/.local/share/gnome-boxes/images/ubuntu-24.04.qcow2 +20G
# 確認
qemu-img info ~/.local/share/gnome-boxes/images/ubuntu-24.04.qcow2
# 3. VM内でパーティションを拡張
sudo growpart /dev/vda 1
sudo resize2fs /dev/vda1
手動スナップショット(BoxesにはUIサポートなし)
# テスト前にスナップショットを作成
qemu-img snapshot -c "truoc-khi-update" \
~/.local/share/gnome-boxes/images/ubuntu-24.04.qcow2
# スナップショット一覧を表示
qemu-img snapshot -l ~/.local/share/gnome-boxes/images/ubuntu-24.04.qcow2
# ロールバック
qemu-img snapshot -a "truoc-khi-update" \
~/.local/share/gnome-boxes/images/ubuntu-24.04.qcow2
VMのクローン作成
cp ~/.local/share/gnome-boxes/images/ubuntu-24.04.qcow2 \
~/.local/share/gnome-boxes/images/ubuntu-24.04-clone.qcow2
アプリを再起動するとBoxesが新しいファイルを自動検出する。
長期利用を決める前に知っておくべき制限
自分のホームラボはProxmox VEで12個のVMとコンテナを動かしている。そのワークフローの中でもBoxesは役立っている — ProxmoxのWeb UIを開きたくないときに、3分でテスト用VMをスピンアップするために使う。ただし誤解しないでほしい:BoxesとProxmoxはまったく異なる問題を解決するものだ。
しかし、Boxesができないことについては現実的に把握しておく必要がある:
- スナップショットUIなし:ターミナルから
qemu-img snapshotを使う必要がある - ブリッジネットワークなし:VMはNATのみで、LAN上に独自IPを持てない
- USBパススルーなし:virt-managerまたはQEMU CLIが必要
- 複数NICなし:デフォルトで1枚のネットワークカードのみ
- パフォーマンスチューニング不可:CPUピニング、hugepages、NUMAの設定ができない
上記の機能が必要なら、virt-managerに移行しよう。Boxesが想定していない使い方を無理やり実装しようとしても意味がない。
まとめ
GNOME Boxesは「すぐに動くVM」が必要なときの正しい選択だ — 深夜2時にlibvirtのドキュメントを読む必要もなく、ストレージプールが何かを理解する必要もない。3回クリックすればVMが動く。新しいOSの試用、クリーンな環境でのパッケージテスト、同僚への素早いデモに最適だ。
ワークロードが複雑になってきたら — 専用ネットワーク、複数ディスク、頻繁なスナップショットが必要になったら — virt-managerに移行するタイミングだ。BoxesはLinuxデスクトップ上での仮想化の世界への最初の入り口として十分な役割を果たしている。それで十分だ。

