こんにちは
ALJの江口と申します。
皆さん、Proxmoxは使ってるでしょうか。
Proxmoxを使って、仮想環境を作るにはKVMとLXCの二つの方式がありますが、どちらで作るかいつも迷います。どちらもOSを入れ、アプリを動かすという使い方では同じですが、仮想マシンとしての特徴が若干違います。今回の記事の前半では、KVMとLXCの特徴の違いについて記載してみました。後半では、ベンチマークを取り、性能に違いがあるか見てみました。
KVMとLXC
KVMはハイパーバイザー型仮想化、LXCはコンテナ型仮想化であることから、以下のような違いがあります。
| 項目 | KVM | LXC（コンテナ） |
|---|---|---|
| オーバーヘッド | ゲストOSのエミュレーションがあり、大きい | ホストOSのカーネルを共有するため、非常に小さい |
| 起動時間 | ゲストOSのブートが必要なため、遅い（数秒～数十秒） | プロセスとして起動するため、速い（一瞬） |
| メモリ消費 | ゲストOS分のメモリが必要で、大きい | ホストOSのカーネルを共有し、必要な分だけ利用するため、小さい |
上記だけを見るとLXCが優れているように見えますが、ProxmoxでLXCを使う上で、以下の注意点があります。
-
OSの柔軟性の欠如
LXCはホストOSと同じLinuxカーネルを共有するため、ゲストOSとしてLinuxディストリビューションしか選択できないため、実行できるOSはLinuxのみです。
KVMはWindows、BSD、など多くのOSを実行できます。 -
セキュリティと分離レベルの低さ
ホストOSとのカーネル共有によるセキュリティリスクがあります。
KVMはゲストOSがホストから独立しており、ゲストOSからホストOSへの干渉は非常に困難で、セキュリティの分離レベルが非常に高いです。
LXCはホストOSのLinuxカーネルをコンテナ間で共有しています。もしコンテナ内で深刻な脆弱性が悪用された場合、ホストOSや他のコンテナに影響が及ぶリスクはKVMよりも高くなります。 -
ライブマイグレーションの制限
LXCはライブマイグレーションが標準でサポートされておらず、マイグレーションの際は一時的にコンテナを停止する必要があります（コールドマイグレーション）。
KVM（VM）は実行中の仮想マシンを停止せずに、別のProxmoxホストへ移動（ライブマイグレーション）できます。高可用性（HA）の維持が必要な場合は重要な機能になります。 -
スナップショット機能の依存性
Proxmoxではスナップショット機能が、使用するストレージ（ファイルシステム）に強く依存します。
LXCではZFSやLVM-Thinなどのボリューム管理機能（CoW: Copy-on-Write）を持つファイルシステムを使用しないと、スナップショットを取れない場合があります。
KVM はqemuで作成すれば、qemuの仮想ディスクイメージ（例：$\texttt{.qcow2}$）でスナップショットを取ることができます。 -
LXCではインストール・動作が難しいアプリケーションがある
コンテナ・仮想化技術（Docker、KVMなど）
Snapパッケージマネージャー（apt、Flatpakは可）
非特権コンテナで許可されない機能（NAT機能、iptables、FUSEなど）
GPUパススルーやUSBデバイスの高度なパススルー
ホストのカーネルバージョンと異なる特定のカーネル機能を要求する場合
LXCは柔軟性においてKVMより劣る面がありますが、オーバーヘッドの少なさに魅力があり、使い分けをすることが大切だと思います。
KVMとLXCをUbuntu25.04で比較してみた
KVMとLXCの特徴の違いについては理解できても、実際はどうなのかというのは気になるところだと思います。Ubuntu25.04をKVMとLXCに入れてみて比較してみました。
ベースとして使ったProxmoxは以下のスペックのハードウェアです。
- cpu： Core i5-1340P(12C16T)
- メモリ：64G
- Disk：NVMe SSD
KVMとLXCで同じOS（Ubuntu25.04）で起動することは可能です。しかし、パッケージまで同じにするのは難しく、逆に無理に合わせるより、普通にインストールした状態の方が実際の利用に近いと思うので、どちらも通常の方法でインストールし、 apt update 直後の状態でテストしました。作成した仮想マシンのスペックは以下の通りです。
| 項目 | ＫＶＭ | ＬＸＣ |
|---|---|---|
| /etc/os-release | Ubuntu 25.04 | Ubuntu 25.04 |
| uname -a | Linux kvm 6.14.0-33-generic | Linux lxc 6.14.11-4-pve |
| core | 4 | 4 |
| memory | 12GB | 12GB |
| disk | 64GB | 64GB |
インストール直後の状態の比較
メモリ使用量
メモリ使用量は顕著に差を感じられる部分だと思います。OSのみであればLXCはほとんど消費せず、KVMは1GB弱必用になります。
ディスク使用量
ファイルシステムもLXCは非常に少なく 0.5GBほどで、KVMは6.6GB消費します。
起動速度
起動速度もLXCが有利な点の一つです。カーネルのロードが必要ないため、必要なプロセスが起動すれば使用可能な状態になります。
起動速度は、それぞれ以下の条件を起動状態として時間を計測しました。
- LXC
# Proxmoxからコンテナ内のコマンド実行が可能になれば起動状態
pct exec $CTID -- uptime 2>/dev/null;
- KVM
# ゲストエージェントのping応答があれば起動状態
qm agent $VMID ping 2>/dev/null;
| 起動 | Time |
|---|---|
| LXC | 1.72秒 |
| KVM | 7.32秒 |
アプリケーションのベンチマーク
アプリケーションを動かして性能に差があるか確認してみます。
まず、LLM推論の推論を実行して結果を比較してみます。
llama.cppには、llama-bench という推論性能の測定のツールがあるので、こちらを実行してみます。
llama-benchの実行
llama-benchは以下のコマンドを実行して計測しました。
使用したモデルは、Mistral 7B Instruct v0.2 の量子化モデル (Q4_K_M)で、約4Gのサイズです。
# 計測に使用したコマンド
./llama.cpp/build/bin/llama-bench -m ./llama.cpp/models/local/mistral-7b-instruct-v0.2.Q4_K_M.gguf --threads 4
- LXCの結果
| model | size | params | backend | threads | test | t/s |
|---|---|---|---|---|---|---|
| llama 7B Q4_K - Medium | 4.07 GiB | 7.24 B | CPU | 4 | pp512 | 17.73 ± 0.05 |
| llama 7B Q4_K - Medium | 4.07 GiB | 7.24 B | CPU | 4 | tg128 | 6.33 ± 0.00 |
build: 03792ad9 (6816)
- KVMの結果
| model | size | params | backend | threads | test | t/s |
|---|---|---|---|---|---|---|
| llama 7B Q4_K - Medium | 4.07 GiB | 7.24 B | CPU | 4 | pp512 | 23.75 ± 0.91 |
| llama 7B Q4_K - Medium | 4.07 GiB | 7.24 B | CPU | 4 | tg128 | 8.50 ± 0.02 |
build: 03792ad9 (6816)
llama-benchの結果
| 特性 | LXC | KVM | 考察 |
|---|---|---|---|
| リソース効率 | 良い | メモリ消費大 | LXCは4GB程度で実行できたが、KVMは8GBほど実行に必要だった。 |
| トークン生成速度 (tg128) 純粋な計算性能 |
6.33 t/s | 8.50 t/s | KVMが優位。 KVMのハードウェアの仮想化支援機能（Intel VT-x / AMD-V）が良い方向で影響してそう。 |
| プロンプト処理速度 (pp512) I/O + 初期処理 |
17.73 t/s | 23.75 t/s | KVMが優位。 virtioドライバによるI/OとCPUの連携がLXCの共有ファイルシステムアクセスを上回ったと思われる。 |
llama-benchの結果では、KVMの方がLXCより30%ほど性能がよいという結果になりました。
MySQLのベンチマーク
MySQLを稼働させてにI/O性能やデータベースの処理能力の比較をしてみます。ベンチマークはsysbenchを使用します。
- テスト環境作成
# テーブル数、テーブルサイズなどを指定してデータを生成
sysbench oltp_read_write --mysql-user=sbtest --mysql-password=password \
--mysql-db=sbtest --tables=10 --table-size=1000000 \
prepare
- ベンチマーク実行
# 60秒間ベンチマークを実行
sysbench oltp_read_write --mysql-user=sbtest --mysql-password=password \
--mysql-db=sbtest --tables=10 --table-size=1000000 \
--threads=4 --time=60 \
run
MySQLベンチマーク実行結果
- LXC
SQL statistics:
queries performed:
read: 176904
write: 50544
other: 25272
total: 252720
transactions: 12636 (210.58 per sec.)
queries: 252720 (4211.64 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 60.0041s
total number of events: 12636
Latency (ms):
min: 2.01
avg: 18.99
max: 815.26
95th percentile: 87.56
sum: 239982.84
Threads fairness:
events (avg/stddev): 3159.0000/17.65
execution time (avg/stddev): 59.9957/0.00
- KVM
SQL statistics:
queries performed:
read: 149002
write: 42572
other: 21286
total: 212860
transactions: 10643 (176.20 per sec.)
queries: 212860 (3523.90 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 60.4036s
total number of events: 10643
Latency (ms):
min: 3.25
avg: 22.67
max: 1318.22
95th percentile: 81.48
sum: 241251.52
Threads fairness:
events (avg/stddev): 2660.7500/6.42
execution time (avg/stddev): 60.3129/0.14
実行結果を表にして比較してみます。
| 指標 | LXC (コンテナ) | KVM (VM) | LXC vs KVM | 考察 |
|---|---|---|---|---|
| トランザクション/秒 (TPS) | 210.58 per sec. | 176.20 per sec. | LXCが約19.5%高速 | 総合性能。LXCのI/O優位性を示す。 |
| 95th パーセンタイル (Latency) | 87.56 ms | 81.48 ms | KVMがわずかに低い | 高負荷時の安定性はKVMが優位。 |
| 平均レイテンシ (Avg Latency) | 18.99 ms | 22.67 ms | LXCが約16.3%低遅延 | トランザクション処理の効率を示す。 |
| 総クエリ数 (Total Queries) | 252,720 | 212,860 | LXCが約18.7%多い | 単位時間あたりの処理量。 |
MySQLのベンチマークテストでは、LXCの方が18%早い結果になりました。
KVMとLXCの比較の考察
アプリケーションの実行テストにおいては、以下のような結果になりました。
llama-bench ではKVMが30%早い
MySQLのベンチ ではLXCが18%早い
速度については、多少得意不得意があるかもしれませんが、それよりも、LXCとKVMでの利用上の違いを理解し、適材適所で利用するのが良いと思います。
LXCはリソース消費が少ないということが魅力的で、KVMは安定的に利用する場合に向いていると思います。
何かの参考になれば幸いです。
以上です。