Proxmoxで使い捨ての検証用VMを数分で作る:Cloud-Initテンプレートの手順
同じ画面を、これまで何回通ったか
ISOを選ぶ。言語を選ぶ。タイムゾーンを合わせる。ディスクの割り当ては既定のまま次へ。ユーザー名を決めて、パスワードを決めて、SSHサーバーにチェックを入れて、あとはインストールが終わるのを待つ。
そうして手に入るのは、まっさらなLinuxが1台です。ここまででだいたい20〜30分。そして、この20分の中に新しく学べることは1つもありません。
社内で説明するときは「毎回インストールするのは二度手間なので、テンプレートを用意しておきます」と言えば、それで通ります。ただ、実際に感じていることは、もう少し違うところにあるかもしれません。同じウィザードを何度もクリックしていくのがしんどい。けれど、それを口にすると面倒くさがっているだけに聞こえそうで言いにくい。その感覚に近いという人は、少なくないと思います。
先に1つ置いておきます。同じ作業を2回目からやらないようにするのは、手抜きではなく段取りです。
この記事では、Proxmox VE(1台のPCの上で複数のサーバーを動かすための仮想化ソフト)で 検証用のLinuxを1台、数分で用意して、終わったら消す ところまでを作ります。
この記事が引き受ける範囲
テンプレートやCloud-Initを調べていると、TerraformやAnsibleといった道具で何十台ものサーバーを一気に立ち上げる事例が目に入ってきます。解説もそういう規模を前提に書かれているものが多く、読んでいるうちに自分の環境が急に頼りなく見えてくることがあります。
ただ、月に1〜2回、検証用に1台作るかどうかという使い方なら、その規模の道具は要りません。N100クラスのミニPCで組んでいる場合はなおさらで、先に詰まるのはCPUではなくメモリの方です(N100 vs N305 vs Ryzen省電力:自宅サーバー向けCPUの選び方、Proxmoxで建てる省電力ホームサーバー)。RAM 16GBの環境で何十台も同時に動かす前提は、そもそも成立しません。
そこでこの記事は、次の1点だけを引き受けます。
検証用のLinuxを1台、数分で用意する。使い終わったら消す。
結論を先に書いておきます。
- テンプレートを作るのは 最初の1回だけ。Proxmoxのシェルでコマンドを7ステップ
- 2回目以降は クローンして名前とIPを入れるだけ。ここは画面操作だけで終わります
- 1台あたりの用意は数分。同じ品質のまっさらな環境が、いつでも出てくる状態になります
「本番の前に試す」を、後ろめたく思わなくていい
本番のサーバーをいきなり触るのが怖い、という感覚そのものは正しいです。一方で「先に検証してから入れます」と言うと「そこまでしなくていいから早く進めて」と返ってきそうで、時間をかけて確かめているところを見せづらい。そう感じている人もいると思います。
事前に確かめたいのは、慎重すぎるからではありません。壊れたときに責任が自分のところへ来ることを、いちばんよく分かっているからです。
そして検証環境は、時間を使う側ではなく 時間を守る側 の設備です。AIに聞いた手順をそのまま本番へ入れる前に一度通す場所としても、ここが要ります。確かめ方そのものはAIに聞いて動いたサーバー設定、そのまま本番に入れて大丈夫?にまとめてありますが、その手順を試す「場所」がなければ、確かめようがありません。この記事はその場所を用意する話です。
どこまでがコピペで、どこからが画面操作か
作り始める前に、境界線を出しておきます。「結局どこかでコマンドが必要になるのでは」という不安は、先に潰しておいた方がいいからです。
| やること | どこで | 頻度 |
|---|---|---|
| テンプレートを作る | Proxmoxのシェル(コマンド) | 最初の1回だけ |
| 検証用VMをクローンする | Web管理画面(右クリック → Clone) | 毎回 |
| ユーザー名・SSH鍵・IPを入れる | Web管理画面のCloud-Initタブ | 毎回 |
| 使い終わったVMを消す | Web管理画面 | 毎回 |
コマンドが必要なのは最初の1回だけで、そこから先はクリックで終わります。テンプレート作成をすべて画面操作で済ませる方法は、現時点ではありません。
なお、ここでいうProxmoxのシェルは、Web管理画面(https://[IPアドレス]:8006)の左側でノード名を選び、Shell ボタンを押すとブラウザの中で開きます。PuTTYなどのSSHクライアントを別に用意する必要はありません。
テンプレートを1回だけ作る
以下は Proxmox VE 9.2系(2026年5月21日リリース)を前提にした手順です。Proxmox自体をまだ入れていない場合は、Proxmoxで建てる省電力ホームサーバーのインストール手順を先に済ませてください。
cloud-init は、OSが初回起動したときに「ユーザー名はこれ、SSH鍵はこれ、IPはこれ」という設定を読み込んで、自分自身をセットアップする仕組みです。これに対応したイメージを使うと、インストールウィザードそのものが要らなくなります。
1. クラウドイメージを持ってくる
クラウドイメージは、cloud-initが最初から組み込まれた、インストール作業なしで起動できるOSイメージです。Proxmoxのシェルで実行します。
cd /root
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
⚠️ ここは注意が必要なところです。Proxmox公式Wikiの「Cloud-Init Support」ページに載っているサンプルは、Ubuntu 18.04(Bionic)のイメージ名のままになっています。18.04は通常のサポート期間を終えたリリースなので、サンプルをそのままコピーすると出発点が古いOSになります。手順の骨格は今も変わっていないので、イメージだけ現行のものに差し替えてください。上のURLはUbuntu 24.04 LTS(Noble)の最新イメージが置かれるディレクトリです。ファイル名は更新されることがあるため、ブラウザで https://cloud-images.ubuntu.com/noble/current/ を開き、-amd64.img で終わるファイル名を確認してから実行すると確実です。
2. 空のVMを作る
qm create 9000 --name ubuntu-2404-template --memory 2048 --cores 2 \
--net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci
9000 はVMID(VMごとの通し番号)です。空いている番号なら何でも構いませんが、テンプレートは9000番台にまとめておくと、普段使うVMと見分けがつきます。vmbr0 はネットワークの接続先(ブリッジ)の名前で、既定の構成ならこの名前です。違う名前にしている場合は、Web管理画面のノード → Network で実際の名前を確認してください。
3. イメージをディスクとして取り込む
qm importdisk 9000 noble-server-cloudimg-amd64.img local-lvm
local-lvm は保存先のストレージ名です。ここは環境によって変わります。 インストール時にLVM-Thinを選んでいれば local-lvm ですが、ZFSを選んだ場合は別の名前になっています。Web管理画面の左のツリーに出ているストレージ名をそのまま使ってください。
コマンドが終わると、取り込まれたディスクの名前が表示されます(vm-9000-disk-0 のような形)。次の手順で使うので控えておきます。
4. 取り込んだディスクを接続する
qm set 9000 --scsi0 local-lvm:vm-9000-disk-0
ディスク名は手順3の出力に合わせます。番号が違えばそのまま書き換えてください。
5. Cloud-Init用のドライブを足す
qm set 9000 --ide2 local-lvm:cloudinit
これが、クローンしたときに設定を流し込む口になります。この1行を忘れると、あとでCloud-Initタブに入力しても中身が反映されません。
6. 起動順とコンソールを設定する
qm set 9000 --boot order=scsi0
qm set 9000 --serial0 socket --vga serial0
1行目で、取り込んだディスクから起動するよう指定します。2行目はシリアルコンソールの設定で、多くのクラウドイメージはこの指定を前提にしています。ただしイメージによっては通常のディスプレイ設定のままの方が画面が出ることもあるため、後述の「つまずきやすいところ」も合わせて見てください。
7. テンプレートに変換する
qm template 9000
これで9000番は起動できなくなり、複製元専用になります。ここまでが最初の1回です。
2回目以降:クローンして、名前とIPを入れる
ここから先は、コマンドを打たなくても終わります。
- 左のツリーでテンプレート(9000)を右クリックして Clone を選ぶ
- 新しいVMIDと名前を入れる(Modeは後述のリンククローン/完全クローンから選ぶ)
- 作られたVMを選び、Cloud-Init タブを開く
- User・Password・SSH public key・IP Config を入れる(IPを決めていなければ DHCP のままで動きます)
- Start を押す
起動が終わった時点で、指定したユーザー名とSSH鍵が入った状態になっています。同じことをコマンドで書くなら、次の3行です。
qm clone 9000 201 --name test-201
qm set 201 --sshkey ~/.ssh/id_rsa.pub
qm set 201 --ipconfig0 ip=192.168.1.201/24,gw=192.168.1.1
IPアドレスとゲートウェイは、自分のネットワークの値に置き換えてください。SSH鍵のパス(~/.ssh/id_rsa.pub)も、鍵を置いている場所に合わせます。
つまずきやすいところ
コンソールに何も表示されない:手順6のシリアルコンソール設定と、使ったイメージの相性です。VMのHardwareでDisplayを既定の設定に戻すと表示される場合があります。SSHで入れているなら、コンソールが映らなくても作業自体は進められます。
ディスクが小さい:クラウドイメージのディスクは数GB程度しかありません。足りないときは、VMのHardwareでディスクを選ぶとサイズを広げる操作ができます。クローンした後でも変更できるので、テンプレート側は小さいままで構いません。
リンククローンと完全クローンの違い:リンククローンはテンプレートのディスクを共有するため、作成が速くディスク消費も小さくなりますが、元のテンプレートを消せなくなります。完全クローンは時間がかかる代わりに、テンプレートから独立した1台になります。使い捨ての検証用なら、リンククローンで問題ありません。
「消すところまで」を1セットにする
この作り方の値打ちは、速く作れることよりも 気軽に壊せること の方にあります。設定を間違えても、パッケージを入れすぎても、数分でまっさらな1台に戻せるからです。
そのためには、消すところまでを1セットにしておくのが大事です。VMを停止してから右クリックで削除すれば、ディスクごと消えます。名前も、本番のVMと取り違えないように test- などを頭に付けておくと安全です。
検証環境が残り続けると、16GBのRAMは静かに埋まっていきます。作ったら消す、を癖にしておくと、この構成のまま長く使えます。
よくある質問
Windowsの検証環境も同じように作れますか
同じ手軽さにはなりません。Windowsゲストは Cloudbase-Init という別の仕組みを使い、Sysprepや手動でのソフト導入が必要になります。無償で配られている既成のクラウドイメージもないため、別作業として見積もった方がいいです。
TerraformやAnsibleも覚えるべきですか
月に1〜2回、検証用に1台作る使い方であれば要りません。それらが効いてくるのは、同じ構成のサーバーを何台も繰り返し作る場合です。この記事の範囲では、覚えることを増やさない方が結果的に早く終わります。
毎回同じパッケージを入れ直すのが面倒です
Proxmoxには、独自の設定ファイル(user-data)をスニペットとして保存し、クローン時に読み込ませる --cicustom という仕組みがあります。ただし、これは自動生成される設定では足りなくなってからで十分です。まずはテンプレート側に必要なものを入れてから qm template を実行する形で足ります。
テンプレートは消してもいいですか
リンククローンで作ったVMが残っている間は、元のテンプレートを消せません。テンプレートを作り直したいときは、9001など別の番号で新しく作り、古い方は使わなくなってから消すのが安全です。
検証用VMは何台まで作れますか
同時に起動する台数はRAMで決まります。N100・16GBの環境なら、Proxmox本体と常時稼働のサービスを差し引いた残りが上限です(Proxmoxで建てる省電力ホームサーバーのRAM試算を参照)。作った台数ではなく、同時に起動している台数だけが効いてきます。
まとめ
- テンプレート作成は最初の1回だけ。Proxmoxのシェルで7ステップ(シェルはブラウザの中で開ける)
- 2回目以降はクローン+Cloud-Initタブへの入力だけで、画面操作で完結する
- 公式Wikiのサンプルは古いイメージのままなので、そこだけ現行のUbuntu 24.04などに差し替える
- ストレージ名・ディスク名・ブリッジ名は環境によって変わる。そこだけ自分の画面で確認する
TerraformもAnsibleも要りません。壊してもいい環境を1台、数分で出せるようになれば、この記事の目的は達成です。そのうえで本番を触れば、「先に試してから入れました」と言える状態が、毎回ついてきます。
検証環境の置き方や、社内サーバーの構成で「これで足りているのか」が自分では判断しづらいときは、状況を書いて送ってもらえれば、こちらの見立てをお返しします。