KVM（Kernel-based Virtual Machine）は、Linuxカーネル自身をハイパーバイザーに変えるカーネルモジュールです。QEMUがデバイスをエミュレートし、libvirtが管理APIを提供する三層構造になっているため、「KVMをインストールする」という表現は正確には成立しません。この記事では、CPU仮想化支援の確認からqemu-kvmの導入、virt-installでの仮想マシン作成、domain XMLの記述、virshでの運用、virt-v2vによるVMware移行までを、実行できるコマンドと公式ドキュメントに沿って追います。ライセンス費がかからない代わりに何を自前で負担するのか、採用を見送る条件も示します。
まとめ：KVM採用の判断軸とVMware移行前に確認する3項目
KVMはLinuxカーネルに組み込まれた仮想化機構で、Intel VT-x／AMD-Vの仮想化支援命令を前提に動きます。単体では動作せず、QEMU（2026年8月26日公開の11.1.1が最新安定版）とlibvirt（2026年9月1日公開のv12.7.0）を組み合わせて初めて実用的な仮想化基盤になります。この三層のどこを触っているのかを把握しないまま構築すると、性能が出ない、ゲストが起動しないといった切り分けで止まりがちです。
移行を検討する場合、着手前に確認すべきは3項目です。第一にホストCPUがvmxまたはsvmフラグを持つこと。第二に移行元ゲストのOSがvirt-v2vの変換対象に入っていること。第三に24時間の商用サポートやVDI基盤としての要件があるかどうか。3番目に該当する案件では、ライセンス費が消えても運用工数と障害対応の責任が自社に移るだけで、総コストは下がりません。KVMが効くのは、Linuxゲストが主体で、カーネルとネットワークを追える技術者が社内にいる基盤です。
KVMがLinuxカーネル上で仮想マシンを動かす仕組みとQEMUの役割
KVMを「VMwareやVirtualBoxのような製品」として捉えると構造を読み違えます。KVMが担うのはCPUとメモリの仮想化だけで、それ以外はすべて別のソフトウェアの担当です。
kvm.koと/dev/kvmが受け持つCPU仮想化支援の呼び出し経路
KVMの本体は、Linuxカーネルに読み込まれるkvm.koと、CPUベンダー固有のkvm-intel.koまたはkvm-amd.koです。KVMプロジェクトの公式サイトは、KVMをIntel VTまたはAMD-Vを備えたx86ハードウェア向けの完全仮想化ソリューションと定義しています。モジュールが読み込まれると、ユーザー空間から扱えるキャラクタデバイス/dev/kvmが現れます。
このデバイスに対するioctlが、仮想マシンの実体です。カーネル公式のKVM API仕様では、KVM_CREATE_VMで仮想マシンのファイルディスクリプタを作り、KVM_CREATE_VCPUで仮想CPUを追加し、KVM_RUNでゲストコードの実行に入る、という三段の呼び出しが規定されています。ゲストが特権命令やI/Oに触れた瞬間にKVM_RUNから制御が戻り、そこから先はユーザー空間側の仕事です。仮想化の全体像とKVM以外の方式との関係は仮想化技術の種類と仕組みを整理した記事で確認できます。
QEMUが引き受けるデバイスエミュレーションとvirtioでの高速化
KVM_RUNから戻ってきた制御を受け取るユーザー空間プロセスが、QEMUです。ディスク、NIC、シリアルポート、PCIバスといった周辺デバイスはQEMUがエミュレートします。QEMU公式のダウンロードページで確認できる最新安定版は11.1.1（2026年8月26日公開）です。
ここで性能を左右するのがデバイスモデルの選択です。IDEやe1000のような実在ハードウェアのエミュレーションは、1回のI/Oごとにゲストからホストへの制御移行が発生します。virtioは実在チップを模倣せず、ゲスト側のドライバとホスト側が共有リングバッファでやり取りする準仮想化インターフェースで、この制御移行の回数を削ります。ディスクとNICはvirtio指定が前提です。指定を忘れたまま本番投入し、ディスクI/Oが想定の数分の一しか出ないという事故は、この1行の設定漏れで起きます。
libvirtとvirshが担う管理レイヤーとdomain XMLの位置づけ
QEMUを直接コマンドラインで起動すると、引数は数十個に膨れます。libvirtはその複雑さをXMLの構成定義に押し込み、統一APIとして提供する管理レイヤーです。libvirtのQEMU/KVMドライバのドキュメントは、システム全体のインスタンスへ接続するURIをqemu:///system、セッション用をqemu:///sessionと定めています。サーバー用途で使うのは前者です。
libvirtは月次で更新が続いており、公式のリリースノートではv12.7.0が2026年9月1日、v12.6.0が2026年8月3日の公開と記録されています。ディストリビューションのパッケージは数バージョン遅れるため、新しいCPU世代のサポートや特定のデバイス指定が通らない場合は、まず手元のlibvirtバージョンとリリースノートの差分を突き合わせます。KVMがLinuxカーネルの一部である以上、この階層構造を追うにはカーネル側の理解も前提です。Linuxの構成とディストリビューションの違いを整理した記事が土台になります。
KVMホストの構築手順：CPU仮想化支援の確認からパッケージ導入まで
構築は3ステップです。CPUが仮想化支援を持つか確認し、パッケージを入れ、KVMが効いているかを検証します。順序を飛ばすと、起動はするがソフトウェアエミュレーションで極端に遅い状態に気付けません。
vmxとsvmフラグの確認：/proc/cpuinfoとkvm-okでの事前判定
KVM公式のプロセッササポート一覧は、Intel系はvmx、AMD系はsvmのフラグを持つCPUが対象だと明記しています。確認は/proc/cpuinfoのflags行を見るのが最短です。
$ grep -o -m1 -E "vmx|svm" /proc/cpuinfo
vmx
$ sudo apt install cpu-checker
$ kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be usedフラグが出力されない場合、CPUが非対応か、BIOS／UEFIで仮想化支援が無効になっているかの二択です。後者は「Intel Virtualization Technology」「SVM Mode」といった項目名で並び、既定で無効な機種が実在します。物理サーバーはOSインストール前に確認しておくと後戻りがありません。クラウド上のVMでKVMを動かす入れ子構成は、ネステッドバーチャライゼーションを許可したインスタンスタイプに限られます。
qemu-kvmとlibvirt-daemon-systemの導入と権限グループ設定
パッケージ構成はUbuntu公式サーバードキュメントのlibvirtの章に沿うのが確実です。同ドキュメントはqemu-kvmとlibvirt-daemon-systemの導入と、管理ユーザーをlibvirtグループへ追加する手順を示しています。sudoグループのメンバーは自動で追加されますが、それ以外のユーザーは手動追加が必要だと明記されています。
$ sudo apt update
$ sudo apt install qemu-kvm libvirt-daemon-system virtinst
$ sudo adduser $USER libvirt
$ newgrp libvirt
$ virsh --connect qemu:///system list --allvirtinstを一緒に入れているのは、次章で使うvirt-installがこのパッケージに含まれるためです。グループ追加はセッションに反映されるまで効かないため、newgrpを挟むか再ログインします。飛ばすと、rootでは動くのに一般ユーザーでは接続を拒否される症状になります。
virsh listとversionで確かめるKVM有効化とQEMU 11.1系の確認
導入が終わったら、KVMアクセラレーションが実際に使われているかを検証します。virsh versionはlibvirt本体、APIライブラリ、ハイパーバイザーの3つを分けて出力するため、パッケージ版数を一度に把握できます。
$ virsh version
Compiled against library: libvirt 10.0.0
Using library: libvirt 10.0.0
Using API: QEMU 10.0.0
Running hypervisor: QEMU 8.2.2
$ lsmod | grep kvm
kvm_intel 376832 0
kvm 1146880 1 kvm_intelRunning hypervisorの行がQEMUのバージョンです。ここがKVMではなくQEMU単体になっていても異常ではありません。判定はlsmodでkvm_intelまたはkvm_amdが読み込まれているかで行います。ゲスト起動後にvirsh dumpxmlの出力先頭がdomain type='kvm'ならアクセラレーションが効いており、type='qemu'ならソフトウェアエミュレーションに落ちた状態です。後者のまま気付かず本番稼働させると、CPU負荷が数倍に膨らみます。
virt-installでVMを作成しdomain XMLでvirtioを設定する作業
仮想マシンの作成は、コマンド1本で定義とインストールを同時に走らせるvirt-installが基本です。作成後の細かい調整はXMLの直接編集に移ります。
virt-installの引数構成：cdrom起動とosinfoの指定で失敗を防ぐ
virt-installのmanページは、名前、メモリ、ディスク、ネットワーク、インストールメディアの指定を必須級の引数として扱っています。ゲストOSの種別を伝える--osinfoを省くと、libosinfoの既定デバイス構成が当たらず、virtioが選ばれないことがあります。
$ sudo virt-install \
--name app01 \
--memory 4096 --vcpus 2 \
--disk size=40,bus=virtio,format=qcow2 \
--network network=default,model=virtio \
--osinfo ubuntu24.04 \
--graphics none --console pty,target_type=serial \
--location /var/lib/libvirt/images/ubuntu-24.04-live-server-amd64.iso,kernel=casper/vmlinuz,initrd=casper/initrd \
--extra-args "console=ttyS0"サーバー用途では--graphics noneとシリアルコンソールの組み合わせが、SSHが通らなくなった時の復旧経路になります。formatにqcow2を選ぶとスナップショットと薄いプロビジョニングが使え、rawならI/O経路が短くなります。データベースを載せる基盤ならraw、開発検証環境ならqcow2という切り分けが実務的です。
domain XMLのcpu mode指定とvirtioディスク・NICの書き方
作成済みゲストの構成はvirsh editで編集します。書式はlibvirt公式のdomain XMLフォーマット仕様が唯一の正で、要素名や属性を推測で書くと定義の読み込み自体が失敗します。CPUの見せ方とディスク・NICのバス指定が、性能に直結する箇所です。
<cpu mode='host-passthrough' check='none'>
<topology sockets='1' dies='1' cores='2' threads='1'/>
</cpu>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none' io='native'/>
<source file='/var/lib/libvirt/images/app01.qcow2'/>
<target dev='vda' bus='virtio'/>
</disk>
<interface type='network'>
<source network='default'/>
<model type='virtio'/>
</interface>cpu modeにhost-passthroughを指定すると、ホストCPUの機能をそのままゲストへ見せるため命令セットを取りこぼしません。引き換えに、異なるCPU世代のホストへのライブマイグレーションができなくなります。複数ホストでクラスタを組むなら、共通の機能セットを定めるhost-modelかカスタム定義を選びます。ディスクのtargetがvdaで始まっていればvirtio、sdaならSCSI、hdaならIDEです。移行してきたゲストがhdaのままになっている例は珍しくなく、ここを直すだけでI/Oが改善します。
ストレージプールとNAT・ブリッジ接続の選び分けとdefaultの扱い
libvirtはディスクイメージの置き場所をストレージプールとして抽象化し、既定でdefaultプールが/var/lib/libvirt/imagesを指します。共有ストレージを使う場合はプールを別途定義し、ホスト間でパスを揃えます。ネットワークは既定のdefaultがNATで、ゲストは外へ出られるが外からは直接届きません。
本番のサーバー仮想化では、物理NICにブリッジを張ってゲストへ直接IPを持たせる構成が基本になります。NATのままだとポート転送の設定が積み上がり、監視や証明書の扱いも複雑です。逆に開発検証用の使い捨てゲストは、NATのdefaultで足ります。この選択はVLANの切り方やファイアウォールの位置まで含めた設計判断です。設計から任せる場合はインフラ構築（AWS・Google Cloud・Azure）の支援で、オンプレミスの仮想化基盤とクラウドを組み合わせた構成の検討から対応できます。
virshで日々の起動・スナップショット・自動起動を回す運用作業
構築後の作業はvirshに集約されます。コマンドで再現できる形にしておくことが、手順書と自動化の土台になります。
virsh start・autostart・consoleで固める日常操作の最小セット
virshのmanページには200を超えるサブコマンドが並びますが、日常的に使うのは十数個です。Ubuntu公式ドキュメントもlist、start、autostart、save、restore、shutdown、editを実例として挙げています。
$ virsh list --all
$ virsh start app01
$ virsh autostart app01
$ virsh console app01
$ virsh shutdown app01
$ virsh domifaddr app01
$ virsh setmem app01 8388608 --config見落としやすいのがautostartです。設定していないゲストは、ホストを再起動すると停止したまま戻りません。カーネル更新後の再起動で一部のゲストだけが上がってこない障害は、これが原因です。domifaddrはゲストのIPアドレスを引く用途で、SSHが通らなくなった時の調査に使います。
snapshot-createとvirsh saveの違いとバックアップ設計の注意点
スナップショットと保存は別物です。snapshot-create-asはディスクとメモリの状態を時点として記録し、saveは実行中のメモリをファイルへ書き出してゲストを停止します。前者は切り戻し用、後者はホスト再起動をまたぐ一時退避用です。
$ virsh snapshot-create-as app01 before-patch --disk-only --atomic
$ virsh snapshot-list app01
$ virsh snapshot-revert app01 before-patch
$ virsh save app01 /var/lib/libvirt/save/app01.state
$ virsh restore /var/lib/libvirt/save/app01.stateqcow2のスナップショットは差分を積み上げる構造のため、世代を残したまま運用するとイメージが肥大し、書き込み性能が落ちていきます。パッチ適用前に取って確認後に削除する運用が前提です。スナップショットはバックアップの代替になりません。ホストのディスクが壊れれば一緒に失われるため、イメージファイルを別ストレージへ複製する仕組みを別途用意します。
VMwareからKVMへvirt-v2vで仮想マシンを移行する手順と落とし穴
ライセンス費を理由にKVMを検討する案件では、既存のVMware環境からの移行が作業の中心です。変換にはvirt-v2vを使います。
virt-v2vの入力指定：vpx://とvmxのどちらを選ぶかの分岐条件
virt-v2v公式のmanページは、vCenter管理下のゲストにはvpx://で始まる接続URIを、ESXiホスト上のVMXファイルを直接読む場合は-i vmx -it sshを使う例を示しています。vCenterがある環境では前者、単体ESXiから吸い出す場合は後者という分岐です。
$ virt-v2v -ic vpx://[email protected]/DC1/esxi01 \
-o libvirt -os default -of qcow2 app01
$ virt-v2v -i vmx -it ssh \
"ssh://[email protected]/vmfs/volumes/datastore1/app01/app01.vmx" \
-o local -os /var/tmp出力先も選べます。libvirt管理下へ直接登録するなら-o libvirt、いったんファイルとして受け取るなら-o localです。同manページは、libvirt出力モードでは通常root権限での実行が必要だと明記しています。OVAファイルなら-i ova、ディスクイメージ単体なら-i diskと、入力形式ごとに指定が変わります。
移行前のクリーンシャットダウンと帯域・一時領域の見積もり基準
virt-v2vのmanページが挙げている前提条件は、実際に事故になる箇所です。ゲストは変換開始前にクリーンシャットダウンする必要があり、稼働させたまま変換をかけるとファイルシステムの破損につながると明記されています。
| 確認項目 | 公式ドキュメントの記述 | 現場での見積もり |
|---|---|---|
| ゲストの状態 | クリーンシャットダウン必須 | 停止可能な時間帯を先に確保 |
| ネットワーク帯域 | ギガビット以上が必要 | 最も効くリソースと明記あり |
| 一時領域の空き | 最低1GB以上 | VIRT_V2V_TMPDIRで移動可 |
| 実行権限 | libvirt出力は通常root | sudo前提で手順書を書く |
数百GBのディスクを持つゲストを何十台も移す計画なら、転送時間が移行スケジュールを決めます。1台あたりの実測を先に取ってから全体計画を引くのが確実です。
KVMを採用する条件と見送る場面：受託開発の現場からの判断基準
KVMは費用がかからない代わりに、責任と工数を自社に引き受ける選択です。この交換が成立する条件は限定されます。
KVMを選ぶ条件：ライセンス費と自前運用体制の損益分岐の見極め
採用が効く条件は4つです。ゲストの大半がLinuxで、カーネルとネットワークを切り分けられる技術者が社内にいて、ハードウェアを保守期限まで使い切る前提があり、構成をコードで管理する運用に移せる。これが揃えば、ライセンス費の削減がそのまま効きます。
逆に、この判断で見落とされやすいのが人件費です。仮想化基盤の障害切り分けができる人材を1人分抱える費用は、中小規模の環境なら商用ハイパーバイザーのライセンス費を上回ります。分岐点は台数と、その基盤に載る業務の停止許容時間です。数十台規模でLinuxゲスト主体、停止許容が数時間あるなら、KVMは合理的な選択になります。コンテナとの棲み分けについてはコンテナと仮想マシンの違いから導入判断までを整理した記事が判断材料になります。
KVMを見送る場面：VDI要件と24時間の商用サポート前提の案件
第一に、仮想デスクトップ基盤としてWindowsクライアントを数百台動かす要件。GPU割り当てとプロトコル、ライセンス管理の作り込みが必要で、専用製品との差が工数として跳ね返ります。第二に、障害時にベンダーへ一次切り分けを預ける前提の運用体制。KVMではコミュニティか自社、あるいはサブスクリプション契約のあるディストリビューションが窓口になり、体制を作らないまま導入すると、障害のたびに復旧時間が伸びます。
第三に、既存のVMware環境に載っているアプライアンス製品がKVM上でのサポート対象外である場合。移行の可否は自社ではなく製品ベンダーの対応範囲に依存し、動いても非サポート構成なら運用リスクが残ります。この3条件のいずれかに当たる案件では、KVM移行を目的にせず、まず何を減らしたいのかへ戻るべきです。費用を減らしたいのか、ベンダー依存を減らしたいのかで、答えは変わります。
よくある質問
KVMの検討時に検索される質問へ、公式ドキュメントの記述と構成上の事実に基づいて答えます。
KVMとVMwareの違いは何ですか？
KVMはLinuxカーネルに組み込まれたモジュールで、ホストOSであるLinuxがそのままハイパーバイザーとして機能します。VMware ESXiは専用のハイパーバイザーOSを物理サーバーへ直接インストールする製品です。KVMはライセンス費用がかからず、管理はvirshやCockpitなど個別のツールの組み合わせになります。ESXiはvCenterによる統合管理と商用サポートが付きます。管理機能とサポートを購入するかどうかの違いとして捉えるのが実務的です。
KVMは無料で使えますか？
KVM本体、QEMU、libvirtはいずれもオープンソースで、ライセンス費用は発生しません。ただしRed Hat Enterprise Linuxなど商用ディストリビューション上で使う場合は、OSのサブスクリプション費用がかかります。UbuntuやRocky Linuxなら費用なしで構築できますが、障害対応と検証は自社の工数です。無料は購入費がゼロという意味であり、運用の総コストがゼロという意味ではありません。
KVMでWindowsは動きますか？
動きます。ゲストとして稼働させられるのはWindows、macOS、FreeBSDなど各種OSです。ただしWindowsゲストではvirtio用のドライバがOSに標準搭載されていないため、virtio-winドライバを別途組み込む必要があります。これを入れないままvirtioを指定するとディスクを認識せずインストールが進みません。逆にIDEやe1000のままではI/O性能が出ないため、インストール時にドライバを読み込ませる手順を織り込みます。
KVMとDockerはどちらを選ぶべきですか？
比較の軸が異なります。KVMはカーネルごと分離した仮想マシンを作る仕組みで、異なるOSやカーネルバージョンを同一ホストで動かせます。Dockerはホストのカーネルを共有してプロセスを隔離するため、起動が速く集約効率が高い一方、カーネルレベルの分離はありません。既存の業務システムをそのまま載せ替えるならKVM、作り直せる前提で密度と配信速度を取るならコンテナという分岐です。排他的に選ぶ必要はなく、KVMのゲスト上でコンテナを動かす構成が一般的です。
KVMのゲストが起動しない場合はどこから調べますか？
切り分けは3段です。まずlsmod | grep kvmでモジュールが読み込まれているかを見ます。次にvirsh startが返すエラー文が、権限の問題かパスの誤りかの判定材料です。それでも原因が見えない場合は/var/log/libvirt/qemu/配下にあるゲスト名ごとのログを確認します。QEMUの起動引数がそのまま記録されているため、domain XMLの指定がどう展開されたかを追えます。
関連記事
- ハイパーバイザーとは？Type1・Type2の違いから仮想化基盤の選定まで実装者向けに解説：KVMがType1とType2のどちらに位置づくか、分類全体を確認できます
- 仮想マシンとは？物理マシン・コンテナとの違いから作成・運用まで実装者向けに解説：KVMが作る仮想マシンの概念と物理マシンとの違いを整理しています
- Proxmox VEとは？できること・日本語化・推奨スペックまで実装目線で解説：KVMとLXCをWeb UIで管理する基盤で、virsh手作業を減らす選択肢です
- Firecracker（マイクロVM）とは？仕組み・KVMとの関係とgVisor・コンテナとの使い分けを実装者目線で解説：同じKVMを土台に起動時間を詰めたマイクロVMとの違いが分かります
- カーネルとは？役割・種類からLinuxカーネルの仕組みまで実装者向けに解説：kvm.koが読み込まれる先のカーネル構造を確認できます
