ProxmoxでLXCとVMをどう使い分けるか：メモリ・バックアップ・Dockerとの相性で判断する
Photo: Brett Sayles / Pexels
先に結論です。単機能の Linux サービス（DNS、ファイル共有など）は LXC、Docker・Home Assistant OS・Windows は VM と分けるのが一番迷いません。LXC は軽くて起動も速い一方、ホストのカーネルを共有するぶん中でできることに制約があります。VM は重いかわりに、ホストから切り離されていて中で何をしても影響が外に出にくいのが強みです。
特に Docker は、Proxmox の公式ドキュメントでも VM の中で動かすことが推奨されています。LXC の中で Docker を動かす構成もよく紹介されていますが、更新をきっかけに動かなくなった事例もあるので、家族が使うサービスを載せるなら VM に寄せたほうが安心です。
なお2026年9月時点の Proxmox VE の最新は、2026年5月に出た 9.2 系とされています。
LXCとVMは「カーネルを共有するかどうか」が違う
| 項目 | LXC（コンテナ） | VM（仮想マシン） |
|---|---|---|
| カーネル | ホストと共有 | ゲストが自分のカーネルを持つ |
| 動かせるOS | Linux のみ | Linux / Windows / 専用OS（HAOS など） |
| メモリ | 使った分だけ消費 | ゲスト OS のぶん多めに必要 |
| 起動 | 数秒 | OS の起動時間がかかる |
| 分離の強さ | 弱め | 強い |
| 別ノードへの移動 | 再起動を伴う | 稼働したまま移せる（クラスタ時） |
LXC は、ホストの Linux の上に仕切りを作って別の Linux のように見せる仕組みです。カーネルは1つだけなので、コンテナの中でカーネルモジュールを読み込む、独自のカーネルを使う、といったことはできません。
Proxmox で新しく作るコンテナは既定で非特権（unprivileged）コンテナになり、コンテナ内の root はホスト側では一般ユーザーとして扱われます。安全のための仕組みですが、そのぶん制約もあります。自宅でよく当たるのは、コンテナの中から NAS の共有フォルダ（NFS / SMB）を直接マウントしにくいことです。ホスト側でマウントして、マウントポイント（バインドマウント）としてコンテナに渡すのが一般的な形です。
メモリ：LXCは使った分だけ、VMはゲストOSのぶん上乗せ
8GB や 16GB のミニPCで一番効いてくるのがここです。
LXC に設定するメモリは「上限」です。DNS サーバーのような小さなサービスなら、実際の消費は上限よりずっと少なく、使っていないぶんはホストや他のコンテナが使えます。OS を丸ごと起動しないので、コンテナを5個、10個と増やしても重くなりにくいのが LXC の利点です。
VM は中でゲスト OS が丸ごと動くため、カーネルやキャッシュのぶん、同じサービスでも LXC より多めに見積もる必要があります。Linux は空きメモリをキャッシュに使うので、割り当てた分をゲストがほぼ使い切ったように見えるのも普通です。Proxmox には使っていないメモリをホストへ戻すバルーニングという仕組みもありますが、私はあてにせず、VM の割り当て合計がホストの実メモリを超えないように組むのが無難だと考えています。
VM を何台も並べたいなら、最初から メモリ32GBのミニPC か、メモリを増設できる機種を選んでおくと後が楽です。
バックアップ：VMはディスクごと、LXCはファイル単位
Proxmox の標準バックアップは LXC も VM も同じ画面から取れますが、中身の取り方が違います。
- VM：稼働したままディスクのデータをコピーするライブバックアップです。Proxmox Backup Server（PBS）に送る場合、変更されたブロックだけを追跡する仕組み（dirty bitmap）で2回目以降が速くなります。ただし VM を停止して起動し直すと追跡情報は消え、次回は全体を読み直すとされています
- LXC：ファイル単位のアーカイブです。稼働中のままスナップショットモードで取るには、コンテナのディスクがスナップショット対応のストレージ（local-lvm の LVM-thin や ZFS など）に置かれている必要があります。PBS に送る場合は pxar 形式になり、メタデータで変更を検出するモードを選ぶと2回目以降の読み込みを減らせます
ここで見落としやすいのが、バインドマウントはバックアップ対象外という点です。公式ドキュメントにも、デバイスやバインドマウントの中身は Proxmox のストレージ管理の外にあるため、バックアップされないと書かれています。ホストでマウントした NAS のフォルダをコンテナに渡している場合、その中身は NAS 側で別に守る必要があります。
スナップショットは空き容量を前提にするので、VM と LXC を置くストレージは NVMe SSD 1TB くらいに余裕を持たせておくと安心です。
Dockerとの相性：公式はVMの中を推奨
Proxmox の公式ドキュメントでは、Docker のようなアプリケーションコンテナは VM の中で動かすことが推奨されています。理由として、ホストからの強い分離と、ライブマイグレーションができることが挙げられています。
LXC の中で Docker を動かすことも、nesting（入れ子）という機能を有効にすれば可能です。Web 画面から非特権コンテナを作ると nesting は既定で有効になっているとされていて、「LXC + Docker」で軽く運用している例は多く見かけます。
ただ、この構成はホスト・LXC・Docker それぞれのセキュリティ機構がうまく噛み合って初めて動いています。2025年11月には、Docker 側（containerd / runc）のセキュリティ修正の後に LXC 内の Docker コンテナが起動しなくなる事象が、Proxmox のフォーラムで多数報告されました。紹介された回避策の中には、AppArmor の制限を外すという、分離を弱める方向の設定も含まれていました。
Proxmox VE 9.1 からは OCI イメージ（Docker Hub などのイメージ）から直接 LXC を作る機能も入りましたが、公式ドキュメント上はテクノロジープレビューの扱いです。
私の結論としては、Debian か Ubuntu Server の VM を1台作り、Docker で動かすものはすべてそこに集めるのが安全側です。VM 1台ぶんのメモリは使いますが、更新で壊れる心配が減り、バックアップも VM 単位で1回で済みます。
迷ったときの判断表
| 載せたいもの | おすすめ | 理由 |
|---|---|---|
| AdGuard Home などの DNS | LXC | 軽く、再起動も速い |
| Samba のファイル共有 | LXC | データはバインドマウントで渡し、NAS 側でバックアップ |
| Docker Compose のサービス群 | VM | 公式推奨。更新で壊れにくい |
| Home Assistant OS | VM | 専用 OS なので LXC では動かない |
| Windows・検証用の別 OS | VM | 自分のカーネルが必要 |
| Jellyfin（iGPU でトランスコード） | どちらも可 | LXC は iGPU を複数コンテナで共有しやすい。VM に PCI パススルーすると基本的にその VM 専用になる |
LXC へのデバイスの受け渡しは、Proxmox VE 8.2 から Web 画面の「Device Passthrough」で設定できるようになっています。
まとめ
- 単機能の Linux サービスは LXC、Docker・HAOS・Windows は VM が基本
- LXC はメモリを使った分だけ消費。VM はゲスト OS のぶん多めに見積もり、割り当て合計が実メモリを超えないようにする
- LXC のスナップショットバックアップにはスナップショット対応ストレージが必要。バインドマウントの中身はバックアップされない
- Docker は公式推奨どおり VM の中へ。LXC + Docker は更新で止まるリスクを承知の上で使う
- 迷ったら VM。重さで困ってから LXC に移しても遅くない
LXC と VM は、どちらか一方に揃える必要はありません。まずは Docker 用の VM を1台と、DNS のような小物を LXC で1つ作り、両方のバックアップと復元を一度ずつ試してみると、自分の環境に合う分け方が見えてくると思います。
運営者が作った Excel テンプレートを BOOTH で配布しています。IT 資産管理台帳（無料 Lite 版あり） / IT 資格の学習管理シート
