ラズパイでProxmox｜自宅サーバー仮想化入門

Proxmox VEは、ブラウザのWeb GUIからVMやLXCコンテナ、バックアップ、スナップショットをまとめて扱える仮想化基盤です。
ラズパイ1台に複数サービスを詰め込んで、1つ壊れただけで全部やり直しになるあの面倒さを、1サービス1ゲストに分けて切り離せる形へ変えてくれます。
もっとも、公式版はx86_64専用で、ラズパイではコミュニティ移植版を使い、動かしやすいのはARM64 Linuxのゲストに限られるので、ここを知らずに始めると詰まりやすいでしょう。
SDカードのままでは遅さと寿命で行き詰まるため、Pi 5・8GBにNVMe SSDとアクティブクーラーを組み合わせ、静的IPとホスト名を先に整えてから進めるのがおすすめです。

Proxmoxで作る自宅ラボのゴールイメージ

Proxmox VEは、ブラウザから自宅サーバー全体をまとめて扱える仮想化基盤です。
VM、LXCコンテナ、バックアップ、スナップショットまでWeb GUIに集約されるので、サービスごとに別のツールを覚え直す必要がありません。
ポート8006の画面を開けば、状態確認から復旧までの流れが一本につながります。

Proxmox VEは『ブラウザで動かす自宅サーバーの管制塔』

最初にこれを入れる理由は明快です。
Proxmox VEの価値は、単に仮想マシンを動かすことではなく、管理の入口をWeb GUIに寄せて運用の迷いを減らせる点にあります。
VMもLXCコンテナも、バックアップもスナップショットも同じ画面から触れるので、Pi-holeだけ別の手順、Home Assistantだけ別の手順といった分断が起きにくくなります。

1台に複数サービスを安全に同居させる発想

筆者が最初にやらかしたのは、Home Assistantとファイル共有を1枚のSDカードに同居させた構成でした。
アップデートのつもりで片方を触っただけなのに、設定の巻き込みで両方が立ち上がらなくなり、復旧に半日かかっています。
1台の中に詰め込むほど、便利さの裏で障害の半径が広がる。
だからこそProxmoxでは1サービス1ゲストに分け、壊しても他へ波及しない形にする意味がはっきりします。

この分離は、単なる整理整頓ではありません。
Pi-hole、WireGuard、Vaultwarden、Home Assistantのように役割が違うものを別ゲストに置くと、再起動も再構築も個別に切り出せます。
新しい設定を試すときも、他サービスの動作を気にせずに済むため、実験環境としての心理的な重さがぐっと下がります。
自宅ラボを「壊れたら全部止まる箱」から「壊れた部分だけ差し替える箱」に変える発想です。

スナップショットで『壊して戻す』を気軽にできる利点

Web GUIから1クリックでスナップショットを取り、設定をいじって、失敗したら即座に戻す。
この往復が数秒で終わるだけで、検証の姿勢がまるで変わります。
業務のインフラ運用でも、変更前の退避点があるだけで作業の緊張感は下がるものですが、自宅ラボでも同じです。
壊す前提で触れるので、気になっていた機能や設定をためらわずに試してみてください。

この「戻せる」安心感があると、学び方そのものが変わります。
エラーを怖がって触らないのではなく、失敗を前提に小さく試す。
Proxmox VEはその流れを自然に作れるので、完成像としてはかなり分かりやすいでしょう。
ただしラズパイで動かすには重要な前提があるため、次章でその条件を見ていきます。

ラズパイでProxmoxは動く？公式非対応という前提

Proxmox VEをラズパイで動かす話は、まず前提をはっきりさせたほうがいいです。
公式リリースはx86_64専用で、ARM向けの公式版はありません。
Pi 4やPi 5で使うなら、Pimox系、ARM64 port、PXVirtのようなコミュニティ移植版を選ぶ現実になります。
移植版は便利ですが、公式サポートや更新の保証は薄く、用途も学習・検証・軽量サービス向けに絞るのが筋でしょう。

公式はx86専用、ARM版はコミュニティ移植

Proxmox VEはブラウザのWeb GUI、標準ポート8006からVM、LXCコンテナ、バックアップ、スナップショットをまとめて扱える仮想化基盤です。
だからこそ、1サービス1ゲストで分けると、壊しても他へ波及しにくい自宅ラボが作れます。
ただし、その土台はあくまでx86_64で、ARM向けの公式版は用意されていません。
ラズパイで触るなら、Pimox系やARM64 port、PXVirtのような移植版を使う前提で考える必要があります。

この前提を知らずに情報を集めると、x86前提の手順とラズパイ移植版の手順が混ざって、かなり混乱します。
実際、x86向けのテンプレートをそのまま当てはめてしまい、動いているのに体感が遅すぎて原因探しに時間を取られました。
後からARM64ゲストに切り替えたところ、同じ構成でも扱いやすさが一気に上がり、最初に前提を固める意味を痛感しました。

動くのはARM64ゲストだけ・x86 VMは現実的でない

ラズパイ上で効率よく動くのは、64bit ARM LinuxのVMかLXCコンテナです。
ここが境目になります。
x86_64のVMを起動するとQEMUのソフトウェアエミュレーションに落ちるため、速度は実用の線を大きく下回ります。
『WindowsをVMで』という発想は、少なくともこの構成では期待しないほうがいいです。
CPUが頑張っても、命令セット自体を翻訳するコストが重すぎます。

その反面、ARM64 Linuxなら話は通ります。
軽いサーバー、検証用のミドルウェア、分離した常駐サービスなら、LXCの軽さも相まって扱いやすいです。
筆者も最初はx86向けテンプレートをそのまま流し込み、遅さに閉口しましたが、ARM64ゲストへ寄せた途端に「使える」感触へ変わりました。
性能差の理由がはっきりしているので、迷いも減ります。

それでもラズパイで仮想化する価値があるケース

ラズパイでProxmoxを使う価値は、重い処理をこなすことではなく、低消費電力で常時起動し、Web GUIで複数サービスを行儀よく分離できる点にあります。
軽量なPi-holeやWireGuard、Vaultwarden、Home Assistantのような役割なら、コンテナで整理して運用しやすいです。
壊しても巻き戻しやすく、学習用の環境としても扱いやすい。
そこが強みです。

逆に、Nextcloudやメディアサーバーのような重い用途をラズパイに押し込むと、仮想化の旨味より苦しさが先に立ちます。
そういう場面ではN100クラスのミニPCに任せ、ラズパイは軽量サービスの管制塔として使うのがきれいです。
筆者の感覚でも、この割り切りがいちばん自然でした。
重い汎用サーバーを目指すより、常時稼働の小さな基盤として組むほうがずっとおすすめです。

必要なハードウェアと最小構成

Pi 5でProxmoxを動かすなら、本体は8GBモデルをほぼ一択として考えるのが自然です。
最大メモリが8GBでも、OSとProxmoxのオーバーヘッドを差し引くと、VMやコンテナに回せる実効領域は概ね5〜6GBに落ちます。
2GBや4GBでは、仮に軽いコンテナを並べてもすぐに壁に当たり、サーバーらしい余裕は出ません。

本体はPi 5・8GB一択に近い理由

Pi 5の8GBは「余るから安心」ではなく、「足りなくなりにくいから現実的」という選び方です。
仮想化では、CPUより先にメモリが詰まりやすく、各VMが少しずつメモリを食うだけで全体の自由度が急に下がります。
2GBモデルは単体サービスの実験向き、4GBモデルでも小さなVMを2つ並べた時点で窮屈になりやすく、Proxmoxを載せる前提では構成の幅が狭すぎます。

ストレージはNVMe SSD必須・SDカードがダメな数値根拠

ストレージはNVMe SSD＋M.2 HATを前提にした方が、最初から失敗しにくいです。
microSDのランダム書き込みは5〜15MB/sと遅く、DockerやLXCのように細かい書き込みが多い用途では待ち時間が目立ちます。
しかもサーバー用途では1〜2年で寿命を迎えやすく、結局は移行と再構築の手間が発生します。
Pi 5のNVMeはPCIe 2.0 x1接続で約400〜500MB/s出せるため、体感は別物です。
筆者もUSBメモリやSDで試した時は書き込みの遅さに耐えられず、NVMe SSDへ移した瞬間にDocker系の操作が目に見えて軽くなりました。
256GBクラスのNVMe SSDは概ね20〜25ドル前後で揃うので、ここを削って安物SDで始めるより、最初から投資した方が長く使えます。
後から作り直す方が高くつく、そう考えてよいでしょう。

アクティブクーラーと電源も妥協しない

常時稼働で仮想化まで乗せるなら、冷却は「念のため」ではなく前提条件です。
アクティブクーラーなしで夏場に回すと、サーマルスロットリングでCPU性能が落ち、コンテナの応答が鈍くなります。
筆者もクーラーなしで試したとき、管理画面の反応がもたつき、軽い更新作業でも待たされる場面が出ました。
そこからはアクティブクーラーと、公式電源相当の安定した給電をセットで考えるようになりました。
性能を最後まで引き出したいなら、冷却と電源はおすすめの中でも最優先です。

Proxmoxインストールの手順

Proxmox は、64bit の Raspberry Pi OS か Debian を土台にして、ネットワーク名とアドレス体系を先に固めてから入れると安定します。
とくに Raspberry Pi では 32bit イメージを避けること、DHCP に頼らず静的IP・ホスト名・/etc/hosts をそろえることが、途中失敗を防ぐ分岐点になります。
導入後は 静的IP]:8006 の Web GUI まで到達し、NVMe 起動を見据えるなら EEPROM 更新と BOOT_ORDER の調整までを最初の準備に含めましょう。

64bit OSの書き込みと初期アップデート

まず 64bit 版の Raspberry Pi OS、または Debian を書き込みます。
32bit OS では動作しないため、ここでイメージを取り違えると、後工程でいくら設定を重ねても前に進みません。
起動できたら apt update で最新化し、基本パッケージを整えてから作業を始めると、途中の依存関係で余計に迷わずに済みます。
ラズパイ上のサーバー構築は、最初の土台がそのまま後半の安定性に直結します。
ここは急がず、確実に進めましょう。

静的IP・ホスト名・hostsを先に揃える

ネットワークは DHCP に頼れません。
静的IP、ホスト名、/etc/hosts の 3 点を導入前に一致させる必要があります。
筆者はホスト名と /etc/hosts の不一致でインストールが途中停止し、原因切り分けに時間を溶かしたことがあります。
あの手戻りを避けるには、IP アドレスだけでなく名前解決までそろえた状態で先へ進むのが正解です。
ここが欠けるとインストールが途中で失敗すると考えておいてください。

リポジトリ追加とproxmox-veインストール

準備が整ったら、コミュニティ移植版のリポジトリを apt のソースに追加し、proxmox-ve をインストールします。
途中でネットワークが切断されたり、設定が一時的にリセットされたりするので、SSH 越しではなくローカル接続のコンソールで作業するのが安全です。
筆者も SSH で始めて接続が落ち、途中からローカルコンソールに切り替えて完走させた経験があります。
導入時は「落ちても続けられる経路」を最初から用意しておくと、気持ちよく進められます。

インストールが終わったら、ブラウザで 静的IP]:8006 にアクセスして Web GUI にログインします。
画面が開けば、基盤としての Proxmox はまず通ったと見てよいでしょう。
NVMe から直接起動したい場合は、ブートローダー（EEPROM）を最新化し、BOOT_ORDER を PCIe 優先に変更する前準備が要ります。
ここを後回しにすると、ストレージ構成の切り替え時に再度詰まりやすくなります。

ログイン後の最初の到達点は、LXC コンテナを 1 つ立てて動作確認し、スナップショットを 1 回取るところまでです。
管理画面に入るだけで終わらせず、実際にコンテナを作って保存操作まで通すと、環境が本当に使える状態かどうかを早い段階で確かめられます。
おすすめです。
ここまで流れで押さえると、その後の増築がかなり楽になります。

VMとLXCコンテナの使い分け

VMは独自のカーネルと仮想ディスクまで抱えるため、分離の強さと引き換えにどうしても重くなります。
最小構成のUbuntu Server VMでもアイドルで約512MBを使い、起動に20〜60秒かかるなら、メモリ5〜6GBのラズパイでは台数を増やすほど息苦しくなるのは自然です。
そこへLXCコンテナを持ち込むと、ホストのカーネルを共有したまま隔離できるので、必要な機能を残しつつオーバーヘッドを大きく削れます。

VMとLXCの違いをメモリと起動時間で比較

違いは、VMが「別のマシンを中に持つ」発想で、LXCが「同じLinuxの上で分けて走らせる」発想だという点にあります。
VMは任意のOSを動かせる反面、カーネル、メモリ管理、仮想ディスクまで個別に抱えるので、常時稼働させるだけでも資源を食います。
LXCコンテナはフルOSではなく、標準的なLinuxサービスを載せるための軽い箱として使えるため、同じラズパイでも同居数に差が出ます。

ラズパイではLXCコンテナが主役になる

業務でVMとコンテナを使い分けてきた感覚を、自宅ラズパイの限られたメモリ事情に翻訳すると答えははっきりします。
最初に何でもVMで立ち上げると、少しサービスを足しただけでメモリが目に見えて減り、起動待ちも積み重なります。
そこでLXCに置き換えると、同じ役割のサービスを複数並べても余裕が残りやすく、Webサーバー、データベース、DNS、スマートホーム、各種自己ホストサービスをまとめて動かしやすくなります。
ラズパイでは「基本コンテナ、必要なときだけVM」という順序で設計するのが現実的です。

VMを選ぶべき場面

VMを選ぶ理由は、単に「安全そうだから」ではなく、完全な分離が本当に必要なときに限られます。
たとえば、セキュリティ上の境界をはっきり切りたい用途や、Linux以外のOSを動かしたい場合、あるいは特殊なカーネル機能を前提にした環境では、LXCでは役目を果たしきれません。
逆に言えば、標準的なLinuxサービスをラズパイで回すだけなら、VMを増やすたびに資源を削るより、LXCで軽くまとめるほうが設計として素直です。

最初に動かす自宅サーバー用途

Pi-holeを最初の一台に選ぶと、自宅サーバーの役割が一気に見えやすくなります。
約50MBのメモリで動き、家庭内ネットワーク全体の広告と追跡をまとめて抑えられるので、ブラウザを開いた瞬間に効果が返ってくるからです。
筆者も最初はLXCコンテナで分離して立て、家族のスマホで広告が消えたときの反応で、常駐サービスの価値をはっきり実感しました。

まず効果が出る軽量サービス

Pi-holeの次に置きやすいのは、外出先から自宅へ安全につなぐWireGuard、自前でパスワードを持てるVaultwarden、家の照明や温度制御をまとめるHome Assistantです。
どれも軽量で、ラズパイでも安定して常駐させやすいので、最初の構成を小さく始めたいときに向いています。
まずは1つ入れて、動作が安定したら2つ目を足す流れにすると、管理の負担が膨らみにくいでしょう。

ラズパイには重い用途と割り切りどころ

ただし、何でもラズパイでこなそうとすると苦しくなります。
NextcloudやメディアサーバーのようにストレージI/Oとメモリを食う用途は、起動後も負荷が残りやすく、同じ手間をかけるならN100クラスのミニPCの方が投資効率が良いです。
筆者もNextcloudをラズパイで無理に動かして重さに悩み、そこから「軽量サービスの常駐基地」として役割を絞り直しました。
割り切ると、機材選びも運用もずっと楽になります。

スナップショットとバックアップで運用を守る

運用を安定させるなら、設定変更の前に各ゲストへスナップショットを取り、戻せる状態を先に作っておきましょう。
小さな変更でも、DNSやVPNの設定を触ると家中の接続に波及するため、巻き戻し手段があるだけで試行錯誤の速度が上がります。
さらに、Web GUIからvzdumpによる構成込みの完全バックアップを定期実行に入れておくと、移設や復旧の手順が単純になります。
最初からこの習慣を仕込んでおくと、安心して触れる土台になります。

つまずきポイントと対処

インストール失敗、起動不可、性能不足の三つに分けて見ると、つまずきは整理しやすくなります。
最初に原因候補を絞れば、場当たり的に再インストールを繰り返す必要はありません。
設定の不整合、起動経路、割り当て過多という順で確認すると、解決までの道筋が見えます。

インストールが失敗する

最頻出なのは、ホスト名・静的IP・/etc/hosts の不整合です。
ここが揃っていないと、インストールの途中で名前解決が崩れ、後半になってから失敗することがあります。
逆に言えば、この3点を先に突き合わせるだけで、原因の切り分けは進みます。
プロキシや追加設定を疑う前に、まず基本の整合性を確認してみてください。

kernel-headers が入っていない場合も、ビルドやインストールが途中で止まります。
特に後からモジュールを追加する流れでは、ヘッダー不足がエラーの引き金になりやすいので、先に入れておくのが安全です。
手順を進めてから不足に気づくと、修復より入れ直しのほうが早い場面もあるため、前倒しの準備が効きます。

NVMeから起動しない・ネットワークが切れる

NVMe から起動しないときは、ストレージ側より先に EEPROM を疑う流れが有効です。
ブートローダーが古いままだと、NVMe 自体は見えていても起動順だけが追従せず、PCIe 優先にしても立ち上がりません。
筆者も EEPROM を更新せずに NVMe 起動でハマったことがあり、ファームウェア更新を入れた途端に一発で抜けました。
順番を間違えず、EEPROM 更新と BOOT_ORDER の見直しから進めましょう。

インストール中に SSH が切れるのも、異常とは限りません。
proxmox-ve のインストール中はネットワーク接続が一時的に切断・リセットされるため、遠隔操作だけで追いかけると不安になりやすいだけです。
ローカル接続のコンソールで作業すれば完走できるので、通信断を故障と決めつけずに進めてください。

VMが落ちる・動作が重い

VM が落ちる、あるいは全体が重くなるなら、まずメモリの割り当て超過を見ます。
実効 5〜6GB を超えて VM やコンテナに回していると、ホスト側の余力が削られて不安定になりやすいです。
重いゲストは LXC へ置き換え、必要量まで割り当てを絞るだけでも、動作は落ち着きます。
筆者も欲張って割り当てた結果、VM が不安定になり、LXC 化と見直しで安定させた経験があります。

性能が足りないと感じたときは、単にスペック不足と片付けず、何にメモリを食われているかを見直しましょう。
仮想化は余裕を積むほど安心に見えますが、実際にはホストの安定分を残すほうが効きます。
まず重いゲストを減らし、必要なものだけを残す運用に寄せるのが。