LinuxでVirtualBoxやVMwareを使って仮想マシンを動かし続けるのは少々もったいない。Fedora WorkstationにはKVMがカーネルに組み込まれており、パフォーマンスはほぼネイティブ、SPICEプロトコルを通じたクリップボード共有やファイル転送も可能で、ライセンスも不要だ。問題は、各コンポーネントの関係を理解していないと、初回のセットアップが混乱しやすいことだ。
筆者はFedoraをメインの開発マシンとして2年間使ってきた。Fedora 40はリリース初日からQEMU 8.2を搭載しており、保守的なディストリビューションは通常数ヶ月遅れになる。この記事では、LinuxおよびWindows 11の仮想マシンを含む、VMのセットアップと最適化の手順をまとめる。
KVM、QEMU、libvirt、Virt-manager — 作業前に正しく理解する
これらの概念を混同している人は多い。実際には4つの独立したレイヤーになっている:
- KVM (Kernel-based Virtual Machine):LinuxカーネルモジュールでCPUをtype-1ハイパーバイザーに変換する。仮想化対応CPU(Intel VT-xまたはAMD-V)が必要。
- QEMU:ハードウェアエミュレーター。CPU、RAM、ディスク、NIC、USBなどをエミュレートする。KVMはハードウェアアクセラレーションによってQEMUを高速化する。
- libvirt:VM管理デーモンで、統一されたAPIを提供する。Virt-managerと
virshはどちらもlibvirtと通信する。 - Virt-manager:libvirtのGUIフロントエンド。使いやすく、日常使用に十分な機能を備えている。
完全なスタック:Virt-manager → libvirt (libvirtd) → QEMU → KVM → CPU hardware
確認とインストール
ステップ1:CPUの仮想化サポートを確認する
egrep -c '(vmx|svm)' /proc/cpuinfo
結果が0より大きければOK。vmxはIntel VT-x、svmはAMD-Vを意味する。0の場合はBIOSで仮想化を有効にする必要がある。
より詳細な確認には:
virt-host-validate
このコマンドはKVM、IOMMU、その他の必要条件を確認する。コマンドが見つからない場合はvirt-managerパッケージを先にインストールする。
ステップ2:必要なパッケージをインストールする
sudo dnf install -y @virtualization
グループパッケージ@virtualizationは必要なものをすべて取得する:virt-manager、libvirt、qemu-kvm、bridge-utils、および関連ツール。個別にインストールするより大幅に手間が省ける。
ターミナルからVMを作成・接続するCLIツールを追加する場合:
sudo dnf install -y virt-install virt-viewer
ステップ3:libvirtdを起動して自動起動を有効にする
sudo systemctl enable --now libvirtd
sudo systemctl status libvirtd
ステップ4:ユーザーをlibvirtグループに追加する
最も見落とされやすいステップ — Virt-managerを開いたときに最も厄介なパーミッションエラーを引き起こす:
sudo usermod -aG libvirt,kvm $(whoami)
その後、グループの変更を反映させるためにログアウトして再ログインする。確認:
groups | grep libvirt
Virt-managerでLinux仮想マシンを作成する
GUIでVMを作成する
Virt-managerを開き、File → New Virtual Machineをクリックする。Local install media (ISO image or CDROM)を選択する。
- ISOファイルを参照する(例:Ubuntu 24.04やDebian 12)
- Virt-managerが自動でOSを検出する — 検出できない場合はドロップダウンから手動で選択する
- RAMとCPUを割り当てる — 最低4GB RAM + 2 vCPU、開発用途なら8GBの方が快適
- ディスクイメージを作成する — Create a disk image for the virtual machineを選択し、サイズは30〜50GB
- ネットワークを確認する — デフォルトのNAT (default)はインターネット接続が必要なVMに適している
ブート前に追加設定を行う場合はCustomize configuration before installにチェックを入れる。
CLIでVMをすばやく作成する
virt-install \
--name ubuntu24 \
--memory 4096 \
--vcpus 2 \
--disk size=40 \
--cdrom /path/to/ubuntu-24.04.iso \
--os-variant ubuntu24.04 \
--network default \
--graphics spice \
--video qxl
利用可能なos-variantを一覧表示して正確に入力する:
osinfo-query os | grep ubuntu
Windows 11仮想マシンをインストールする
WindowsはLinuxと比べて追加ステップが必要だ:QEMUの仮想ディスクとNICを認識させるためにVirtIOドライバーをインストールする必要がある。このドライバーを用意しないとWindowsインストーラーがディスクを認識できず、インストール後に気づいても後の祭りだ。
VirtIOドライバーのISOをダウンロードする
wget https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso
正しい設定でWindows VMを作成する
virt-install \
--name windows11 \
--memory 8192 \
--vcpus 4 \
--disk size=80,bus=virtio \
--cdrom /path/to/Win11.iso \
--disk /path/to/virtio-win.iso,device=cdrom \
--os-variant win11 \
--network default,model=virtio \
--graphics spice \
--video qxl \
--tpm emulator,model=tpm-crb,version=2.0
--tpmオプションはWindows 11で重要 — TPM 2.0が必須要件となる。QEMUはswtpmを通じてTPMをエミュレートする:
sudo dnf install -y swtpm swtpm-tools
Windowsのインストール中、インストーラーがディスクを表示しない場合:Load driverをクリック → virtio-win CDROMを参照 → viostor/w11/amd64フォルダーを選択 → OK。するとディスクが表示される。
VMのパフォーマンスを最適化する
ディスクとネットワークにvirtioを使用する
Virt-managerはデフォルトで古いエミュレーション(IDE、e1000)を使う場合がある。VM Detailsセクションでvirtioに変更する:
- ディスク:バスがIDEやSATAではなく
virtioになっていることを確認する - NIC:モデルを
e1000eからvirtioに変更する
差は歴然だ:virtioを使ったVM内のシーケンシャルリードは約1.2 GB/sに達するが、IDEエミュレーションでは300〜400 MB/s程度にとどまる。大規模プロジェクトのコンパイルやデータベース実行時に体感できる差だ。
Linux VMの場合、virtioドライバーはカーネルに含まれているため追加インストールは不要だ。Windowsの場合は、先ほどダウンロードしたvirtio-win ISOからインストールする。
高負荷ワークロード向けのCPUピニング
コードコンパイルやレンダリングにVMを使う場合、CPUピニングを試す価値がある — ホストOSとVMが同じコアを奪い合うと不均一なレイテンシスパイクが発生するが、ピニングでこの問題を解決できる:
# ホストのCPUトポロジーを確認する
lscpu -e
# VMをコア2〜5にピン留めする(ホストOS用にコア0〜1を確保)
virsh vcpupin windows11 0 2
virsh vcpupin windows11 1 3
virsh vcpupin windows11 2 4
virsh vcpupin windows11 3 5
virshでスナップショットを素早く作成する
# テスト前にスナップショットを作成する
virsh snapshot-create-as ubuntu24 snap-before-upgrade "Before kernel upgrade"
# スナップショットを一覧表示する
virsh snapshot-list ubuntu24
# スナップショットにロールバックする
virsh snapshot-revert ubuntu24 snap-before-upgrade
スナップショットの作成は2〜3秒で完了し、ロールバックも同様だ。VMで危険な操作を試みる前には必ず作成しておく — 最初からインストールし直すと1時間以上かかる。
GUIなし環境でCLIを使ってVMを管理する
# すべてのVMを一覧表示する
virsh list --all
# VMの起動・停止
virsh start ubuntu24
virsh shutdown ubuntu24
virsh destroy ubuntu24 # 電源を抜くような強制オフ
# コンソールに接続する(GUIのないサーバーVM向け)
virsh console ubuntu24
よくあるエラーの対処法
VM起動時の”cannot access storage file”エラー
最もよくある原因はディスクイメージを格納するフォルダーのパーミッション問題だ。libvirtはqemuユーザーで動作するため、フォルダーにアクセスできる必要がある:
sudo chown -R qemu:qemu /var/lib/libvirt/images/
sudo chmod 755 /var/lib/libvirt/images/
ディスクイメージを/home/user/vms/などのカスタムフォルダーに置いている場合は、SELinuxコンテキストを追加する必要がある — FedoraではSELinuxがデフォルトで有効なため、これはよくあるエラーだ:
sudo semanage fcontext -a -t virt_image_t "/home/user/vms(/.*)?"
sudo restorecon -Rv /home/user/vms/
VMがインターネットに接続できない
# デフォルトネットワークが稼働しているか確認する
virsh net-list --all
# "default"ネットワークが非アクティブの場合
virsh net-start default
virsh net-autostart default
まとめ
2年間毎日使ってきて、FedoraのKVM/QEMUに失望したことは一度もない。LinuxのVMでスクリプトをテストするのもスムーズで、特定のソフトウェア用のWindows VMも問題なく動作する — virtioを使ったディスクI/OはVirtualBoxより明らかに速く、通常のワークロードではCPUオーバーヘッドはほぼ感じられない。
見落としやすい3つのポイント:libvirtグループへのユーザー追加を忘れる、Windowsインストール前にVirtIOドライバーを用意しない、そしてlibvirtdの起動を忘れる。この3つのうちどれか一つに引っかかると、不要なデバッグに30分以上費やすことになる。それ以外はVirt-managerが直感的に処理してくれる — CI/CDやネットワークラボなどの重いワークロードには、network bridgeとstorage poolについてさらに調べると良いだろう。

