以前は、仮想化関連やストレージの仕事をしていたので、仮想マシンホストが大量にあったが。。。
台数が多いと電気代が高い、暑い、うるさい、暑い、の三重苦
-
近頃の原油高ー＞電気代が高い
-
地球温暖化ー＞外気すら暑い
-
暑いところで利用ー＞FANが猛烈に回転してうるさい
正しく、現代の政治、環境問題の全ての影響を受けている。さらに仮想マシン中心のホームラボは、ホストの台数そのものが増える。こうしたシステムは居間や寝室には置きづらく、結局は専用のスペースが必要になる。今や都内ではマンション価格が1億円を超えることも珍しくない。そう考えると、電気代だけでなく、サーバのフットプリントそのものがコストになっている。
つまり、仮想環境のホームラボは、現代の問題の多くの影響を受けてしまっている。
運用の面からみると、一般的な仮想マシンテンプレートの管理やらホストの設定をGUIで行う。自分は、だいぶ自動化、CLI化をしていたが、そこまでたどり着くのががものすごく大変だった。
自分の用途では、以前ほどメリットを感じなくなった。
今のアプリは、仮想マシンである必要なソフトウェアがだいぶ減ってきて、コンテナベースで動くものが多くなってきている。知らない人からみたら、ローカルLLMは巨大サーバや仮想マシンと思うかもしれないが、そんなことはなく、コンテナで十分というか、ソフトウェアスタックの開発、設定のためにコンテナが主流。自宅ラボやローカルLLM用途では、少なくとも自分の環境では、あえてコンテナ on 仮想マシンにする必要性は薄くなった。
さらにコンテナは、作ったり消したりが楽なので、仮想マシンのように環境保存でディスクサイズ丸々消費ということもなく、ホスト自体も少なくできるので、ホストもストレージもそれほど増えない。
Agent AIの観点で見ると、この数年でインフラ運用の流れは大きく変わった。
以前なら、
-
ググって設定を調べて、手で設定を適用
最近までは、
-
AIに設定を聞いて、手で設定を適用
だった。
しかし Agent AI を導入すると、
-
AIに指示を出して、AIが設定を適用
になる。
つまり、人間が設定方法を調べて実行するのではなく、AIがCLIやAPIを使って実際の設定作業まで行う。もちろん、まだ辿々しい部分はあるし、時々間違えることもある。それでも、事前に必要な情報や権限を与えておけば、かなりの部分を自動で実行してくれる。ちなみに、去年の今頃はここまでできなかった。
ということは、Agent AIにインフラを操作してもらうためには、Agent AIが動かしやすいプラットフォームにしておくべきではないか？と思って比較してみた。
比較対象は、有名どころの仮想環境とコマンドライン、APIでいろいろできるIncus（LXDから派生したプロジェクト）の３つを代表例で比較してみた。
Agent AIから見た理想
Agent AIは
-
GUIが苦手
-
CLIが得意
-
REST APIが得意
Open WebUIのOpen Terminalがどこまでできるのかを調べてるために、先日、試しに
「EdgeRouterにログインして設定を調べ、192.168.10.6のマシンをWake-on-LANで起動して」
と指示してみた。
するとAIは、
- 踏み台サーバを経由してEdgeRouterへ接続し、
- 設定ファイルからDHCP静的割り当てを解析し、
- 対象ホストのMACアドレスを特定し、
- 最終的にWake-on-LANパケットを送信した。
もちろん本当に起動したかの確認までは不十分だったが、少なくとも『設定を調べて手順を説明するAI』ではなく、『実際に作業を実行するAI』になりつつあることを実感した。ここまでやるかぁと思った。Open Terminalはインフラがさわれないターミナルととインフラをさわれる管理用のターミナルの２つを作っているので事故は起きにくなっているが、ここまでやるとは正直驚いた。
従来は
ESXi > Proxmox > Incus
みたいな評価になりがちだったが、これは、あくまでも人間がGUIで管理する前提での評価。つまり、Agent AIレス。
AIがCLI/APIで操作する前提だと、
Incus > Proxmox > ESXi
10年前なら誰も予想をしなかった順番になっている。もっと言えば、古くの環境にはGUIはなく、その後GUIがついてきた。しかし、また、今は、GUIよりテキスト端末、もっと言えばAPI。しかし、人間が介在する限りは、なんらかのインタフェースが必要。実は、Agent AIがでてきて、人間がシステムの触る場所、見る場所が大きく変わりつつある。それが、今流行りの可視性（モニタリング）の部分につながっているのかもしれない。
全体的に比較すると
|
基盤
|
人間向け
|
Agent向け
|
|---|---|---|
|
ESXi
|
◎
|
△
|
|
Proxmox
|
◎
|
○
|
|
Incus
|
○
|
◎
|
Agent AI視点
Agent AIにOSのインストールからをさせることはできないので、やはりOSのテンプレートがあるのが便利。そもそも、クラウドだともうWindowsもLinuxもOSのインストールなんてすることはない。Incusは、Linuxに限ってはクラウドと同じようなイメージが使える。Windowsは、どのプラットフォームでも作る必要があるのは変わらないが。
|
項目
|
Incus
|
Proxmox
|
ESXi
|
|---|---|---|---|
|
AIが状態取得
|
◎
|
○
|
○
|
|
AIがVM作成
|
◎
|
○
|
△
|
|
AIが削除
|
◎
|
○
|
△
|
|
AIが再構築
|
◎
|
○
|
△
|
|
AIがテンプレート管理不要
|
◎
|
△
|
×
|
|
REST API利用
|
◎
|
○
|
○
|
|
CLIだけで完結
|
◎
|
○
|
△
|
VM作成の差
Incus
incus launch images:ubuntu/24.04 test –vm
完了。そういう観点でみると、Incusは都合がいい。
Proxmox
Cloud Image取得
↓
VM作成
↓
CloudInit設定
↓
Template化
↓
Clone
Cloud-initの作成が肝になってしまう。また、ProxmoxでもCloud-initは利用できるが、設定可能な項目や実装方法が異なるため、クラウド向けのCloud-init設定をそのまま持ち込めるわけではない。（個人的には、Cloud-initの一部だけ実装されたものと感じる。）
ESXi
OVA準備
↓
Import
↓
Template化
↓
Clone
OVAにしない場合は、Proxmoxと同じ方法、ただし、VMwareは、純粋なCloud-initを入れることができるので、この点だとまだ、Proxmoxよりマシ。
Open Terminalとの相性
|
項目
|
Incus
|
Proxmox
|
ESXi
|
|---|---|---|---|
|
Open Terminalから操作
|
◎
|
○
|
△
|
|
sudoだけで完結
|
◎
|
○
|
×
|
|
API認証設定
|
簡単
|
普通
|
面倒
|
|
スナップショット
|
◎
|
○
|
○
|
|
使い捨て環境
|
◎
|
○
|
△
|
K3sラボ用途
K3sのラボ作成は、どのプラットフォームを使ってもそれほど大差はないが、ホストOS構築後の比較なので注意。
|
項目
|
Incus
|
Proxmox
|
ESXi
|
|---|---|---|---|
|
K3s構築
|
◎
|
◎
|
◎
|
|
KubeVirt検証
|
◎
|
◎
|
◎
|
|
Longhorn検証
|
◎
|
◎
|
◎
|
|
VM複製速度
|
◎
|
○
|
○
|
|
破壊→再作成
|
◎
|
○
|
△
|
Open WebUI Terminal向けの用途
|
項目
|
Incus
|
Proxmox
|
ESXi
|
|---|---|---|---|
|
AI実験
|
◎
|
○
|
△
|
|
MCP連携
|
◎
|
○
|
△
|
|
Agent AI実験
|
◎
|
○
|
△
|
|
Sandbox環境
|
◎
|
○
|
△
|
|
K3s自動構築
|
◎
|
○
|
△
|
|
CLI完結
|
◎
|
○
|
×
|
実際の運用イメージ
Incus
Open Terminal
↓
incus launch
↓
Ubuntu VM
↓
K3s
↓
テスト
↓
incus delete
Proxmox
Open Terminal
↓
qm clone
↓
Ubuntu VM
↓
K3s
↓
テスト
↓
qm destroy
テンプレート管理が必要。
ESXi
Open Terminal
↓
govc clone
↓
Ubuntu VM
↓
K3s
↓
テスト
↓
削除
vCenterやテンプレート前提になりがち。
まとめ
Agent AI / Open Terminal 時代という観点で比較すると、かなり評価が変わります。
総合比較
|
項目
|
Incus
|
Proxmox VE
|
ESXi
|
|---|---|---|---|
|
ライセンス
|
OSS
|
OSS
|
商用中心
|
|
ホストOS
|
Linux
|
Linux
|
独自OS
|
|
VM
|
○
|
○
|
○
|
|
コンテナ
|
○ (Native)
|
○ (LXC)
|
×
|
|
API
|
◎
|
○
|
○
|
|
CLI
|
◎
|
○
|
△
|
|
GUI依存
|
低
|
中
|
高
|
|
AIとの親和性
|
◎
|
○
|
△
|
|
自動化
|
◎
|
○
|
○
|
|
学習コスト
|
低
|
中
|
高
|
|
リソース消費
|
小
|
中
|
大
|
では商用環境でIncusがお勧めかというと、必ずしもそうではない。技術的には優秀だが、ESXiやProxmoxに比べると導入実績、サポートベンダー、構築パートナーはまだ少ない。そのためホームラボや、環境を自前で構築・運用できるサービスプロバイダー向けと言える。
自分の評価
|
用途
|
最適
|
|---|---|
|
Open Terminal実験
|
Incus
|
|
Agent AI実験
|
Incus
|
|
K3s検証
|
Incus
|
|
KubeVirt検証
|
Incus
|
|
企業向け仮想化学習
|
ESXi
|
|
仮想化管理GUIを楽しむ
|
Proxmox
|
|
自宅ラボ
|
Incus
|
|
AIが勝手に環境構築するデモ
|
Incus
|
今やろうとしている
Ubuntu 26.04
↓
Incus
↓
Ubuntu VM
↓
K3s
↓
KubeVirt
は、実は「AIがインフラを構築するデモ」として非常に相性が良い。
特に Incus は、
incus launch images:ubuntu/24.04 demo –vm
だけで Ubuntu VM が出てくるので、Agent AIにとっては、Terraformやスクリプトを事前に用意しなくても、1コマンドでVMを作れるため扱いやすい。
30年前
人間がテキストターミナルを操作
20年前
人間がGUIを操作
10年前
人間がAPIを操作
現在
AIがAPIを操作
評価軸そのものが変わった。
Incusが最強という話ではない。
企業で大量のWindows VMを管理するなら、今でもESXiやProxmoxが有力な選択肢だろう。
しかし、Open TerminalやAgent AIを使い、AI自身にインフラを構築・破壊・再構築させるという観点で見ると、評価軸は大きく変わる。
20年前、仮想化製品の評価はGUIだった。
10年前はAPIだった。
そして今、
「AIが扱いやすいか」
という新しい評価軸が生まれつつある。
変わったのは製品ではない。
変わったのは、システムを操作する主体なのかもしれない。