KVM(Kernel-based Virtual Machine)とは何か

[hiramekun]

[claude]

Claude finished @hiramekun's task in 1m 53s —— View job

---

作業状況

• コンテキストの確認
• 既存 issue の重複・関連チェック(重複なし、gVisor(runsc)とは何か(runc との違いと使いどころ) #70 gVisor を関連ノートとしてリンク)
• KVM についての解説を作成
• タイトルの編集(「KVM(Kernel-based Virtual Machine)とは何か」)
• ラベル付与(infra, type:concept)

---

概要

KVM(Kernel-based Virtual Machine) は、Linux カーネルにハイパーバイザー機能を追加するカーネルモジュールです。Intel VT-x や AMD-V といった CPU の仮想化支援機能(ハードウェア仮想化拡張)を利用して、Linux カーネル自体を「ハイパーバイザー」として動作させます。単体では I/O デバイスのエミュレーションを持たないため、通常は QEMU と組み合わせて使い、QEMU がユーザー空間でデバイスエミュレーションを担当し、CPU・メモリの仮想化を KVM がカーネル空間で高速に処理する、という役割分担になっています。

flowchart TB
    subgraph Guest["ゲストVM"]
        GOS["ゲストOS"]
    end

    subgraph Userspace["ホストのユーザー空間"]
        QEMU["QEMU プロセス\n(vCPUスレッド / デバイスエミュレーション)"]
        Libvirt["libvirt\n(管理レイヤ)"]
    end

    subgraph Kernel["ホストの Linux カーネル空間"]
        KVMmod["KVM カーネルモジュール\n(/dev/kvm)"]
        Sched["Linuxスケジューラ"]
    end

    HW["CPU\n(Intel VT-x / AMD-V)"]

    Libvirt --> QEMU
    GOS -.実行.-> QEMU
    QEMU -->|ioctl| KVMmod
    KVMmod --> Sched
    KVMmod --> HW

Loading

何が嬉しいのか

• ハードウェア支援によるほぼネイティブな実行速度: KVM 登場以前の QEMU 単体(TCG によるフルソフトウェアエミュレーション)や、Bochs のような完全エミュレータでは CPU 命令を1つずつソフトウェアで解釈する必要があり大幅なオーバーヘッドがありました。KVM は VT-x/AMD-V を使ってゲストの特権命令をハードウェアレベルで直接実行するため、ネイティブに近い性能が出ます。
• 専用ハイパーバイザーOSが不要: Xen や VMware ESXi のような「ベアメタル型(Type-1)」ハイパーバイザーは、それ自体が独立した OS として動作します。KVM は普段使っている Linux カーネルにモジュールを1つ組み込むだけでホストがハイパーバイザーになるため、既存の Linux 運用ノウハウ(パッケージ管理、ネットワーク設定、監視など)をそのまま活用できます。
• クラウド基盤の事実上の標準: OpenStack (Nova)、oVirt/RHV、Proxmox VE、そして Google Compute Engine や AWS の一部(Nitro の前身)など、多くのクラウド/仮想化基盤の内部で KVM が使われています。

詳細

• 仕組み: KVM を有効にすると /dev/kvm というデバイスファイルが現れます。QEMU などのユーザー空間プロセスはこれを ioctl() で操作し、VM の作成・vCPU の作成・ゲストメモリ領域の割り当てなどを行います。ゲストの vCPU は実体としてはホスト上の1スレッドとして扱われ、Linux の通常のスケジューラでスケジューリングされます。
• CPU/メモリ仮想化 vs デバイスエミュレーション: KVM が担当するのは CPU の実行モード切り替え(VMX root/non-root モード)とメモリ仮想化(EPT/NPT によるネストしたページテーブル)です。ディスクやNIC、GPUなどのデバイスは KVM の範囲外で、QEMU がソフトウェアエミュレーションするか、virtio というパラ仮想化ドライバをゲストにインストールすることで、エミュレーションのオーバーヘッドを削減できます。
• 管理ツール: 実運用では QEMU を直接叩くのではなく、libvirt (virsh コマンドなど) や、それを使う Proxmox / oVirt / OpenStack といった上位ツールで VM のライフサイクル(作成・起動・ライブマイグレーション・スナップショット)を管理するのが一般的です。
• 前提条件: BIOS/UEFI で Intel VT-x(または AMD-V)が有効になっている必要があります。ネストした仮想化(VM の中でさらに KVM を使う)を使う場合は kvm-intel nested=1 のような追加設定が必要です。
• コンテナとの違い: Docker などのコンテナは同じホストカーネルを共有してプロセスを分離するのに対し([[cgroup と namespace はどのように Docker のコンテナ化技術を支えているか #66]] の namespace/cgroup、[[Docker における seccomp / seccomp-bpf によるsyscallフィルタリング #67]] の seccomp などが該当)、KVM の VM はゲストごとに独立したカーネルを持つため、隔離レベルがより強固です。この特性を活かし、コンテナの API 互換性を保ちながら KVM の隔離を使う Kata Containers のような技術もあります。

参考リンク

• KVM 公式サイト (Linux Kernel Virtual Machine)
• QEMU 公式ドキュメント
• libvirt 公式ドキュメント
• Red Hat: Kernel-based Virtual Machine (KVM) とは

関連ノート

• gVisor(runsc)とは何か(runc との違いと使いどころ) #70 gVisor(runsc)とは何か(runc との違いと使いどころ) — gVisor(runsc)とは何か(runc との違いと使いどころ) #70 : どちらも「未信頼なワークロードをどう隔離するか」という文脈で語られますが、KVM はハードウェア仮想化による VM 単位の隔離、gVisor はユーザー空間の擬似カーネルによる syscall 単位の隔離という異なるアプローチです。