前回は、Proxmox VE 9.2上にUbuntu Server 26.04 LTSのVMを作成し、ログイン画面まで確認しました。今回は、そのVMを日常的に壊さず扱うため、QEMU Guest Agent、起動と停止、Console、スナップショットの基本を確認します。
実際に操作するのはStart・Shutdown・noVNC Console・スナップショットの作成と一覧確認までです。強制操作のStop・Reset、現在の状態を失う可能性があるRollback、スナップショットを消すDeleteは実行しません。
重要：スナップショットはバックアップではありません。重要データがこのVMにしかない場合は、先に別の保存先へバックアップを用意してください。
この記事で行う7手順
- 作業範囲とVMの現在状態を確認する
- UbuntuへQEMU Guest Agentをインストールする
- VMを正常終了してProxmox側のGuest Agentを有効にする
- 完全停止後にStartし、Guest Agentの応答を確認する
- Start・ShutdownとStop・Resetを使い分ける
- noVNC ConsoleとSSHの役割を確認する
- 停止中VMのスナップショットを作成して確認する
手順1：作業範囲とVMの現在状態を確認する
対象VMをStartし、SummaryでRunning、ConsoleでUbuntuのログイン画面が表示されることを確認します。ログイン後は次の読み取り専用コマンドで、OSとファイルシステムの空き容量を確認します。
cat /etc/os-release
df -h /今回は設定直後の検証用VMを前提にします。すでにサービスやデータベースを運用しているVMでは、停止時間とアプリケーション固有の整合性確認を別に計画してください。
- 実行する：Guest Agent導入、Start、Shutdown、Console、Snapshot作成
- 実行しない：Stop、Reset、SnapshotのRollback、Delete
- 変更しない：CPU、メモリ、ディスク、Bridge、VLAN、IP設定
停止条件：Ubuntuが正常起動しない、ファイルシステムに異常がある、重要データがこのVMにしかない、ストレージ警告が出ている場合は作業を始めません。
手順2：UbuntuへQEMU Guest Agentをインストールする
ConsoleまたはSSHでUbuntuへログインし、公式リポジトリから qemu-guest-agent をインストールします。
sudo apt update
sudo apt install qemu-guest-agentUbuntu 26.04 LTS（Resolute）には qemu-guest-agent パッケージが提供され、qemu-guest-agent.service が含まれています。パッケージ導入直後はProxmox側の通信用デバイスがまだ有効でないため、サービスがactiveにならない場合があります。この段階ではインストールが正常終了したことだけを確認します。
dpkg-query -W -f='${Status}
' qemu-guest-agentinstall ok installed と表示されればUbuntu側の導入は完了です。サービスの最終確認は手順4で行います。
qemu-guest-agent — Ubuntu公式パッケージ / パッケージのファイル一覧 — Ubuntu公式
停止条件：apt updateが失敗する、パッケージが見つからない、インストールがエラー終了する場合は、非公式リポジトリを追加せず原因を確認します。
手順3：VMを正常終了してProxmox側のGuest Agentを有効にする
Ubuntuへパッケージを入れるだけではGuest Agentの設定は完成しません。まずUbuntu内で実行中の処理がないことを確認し、Proxmox Web UIの対象VMでShutdownを選びます。VMがStoppedになるまで待ちます。
Stoppedを確認後、対象VMのOptions → QEMU Guest Agent → Editを開き、Use QEMU Guest Agentを有効にします。Freeze-fs-on-backupなどの追加項目は、バックアップ方式とアプリケーション整合性に関係するため、今回は初期値から変更しません。
Guest Agent設定をVMへ反映するには、稼働中の再起動だけで済ませず、完全停止後の新しいStartを行います。
QEMU Guest Agent — Proxmox VE公式
停止条件：Shutdownが完了しない、タスクログにエラーがある、Optionsの設定内容が分からない場合はStopで強制終了せず、ConsoleでUbuntuの状態を確認します。
手順4：完全停止後にStartし、Guest Agentの応答を確認する
VMがStoppedであることを確認してStartします。Ubuntuへログインし、サービス状態を確認します。
systemctl is-active qemu-guest-agent
systemctl status qemu-guest-agent --no-pageris-active が active、statusに active (running) と表示されればUbuntu側は正常です。自動起動の設定を推測で追加せず、Ubuntuパッケージと仮想デバイスの標準動作を使います。
Proxmox側ではSummaryにゲストOSから取得した情報が表示され、Guest Agent未応答の警告が出ていないことを確認します。さらに読み取り専用で確認する場合は、Proxmox NodeのShellでVMIDを実際の番号へ置き換えて実行します。
qm guest cmd <VMID> pingエラーなく終了すればProxmoxからGuest Agentへ到達できています。VMIDは前回作成時にProxmoxが割り当てた番号を使い、記事の例へ合わせません。
停止条件：サービスがinactive・failed、Proxmox側に未応答警告がある、pingが失敗する場合は正常と判定しません。VMのOptionsと完全停止後のStartを再確認します。
手順5：Start・ShutdownとStop・Resetを使い分ける
| 操作 | 意味 | 今回実行 | 基本方針 |
|---|---|---|---|
| Start | 停止中VMを起動 | する | 通常操作 |
| Shutdown | ゲストOSへ正常終了を要求 | する | 停止時は原則これ |
| Stop | QEMUプロセスを即時停止 | しない | 電源断に近い強制操作 |
| Reset | VMを強制リセット | しない | 通常の再起動には使わない |
Guest Agentが有効かつ応答していれば、ProxmoxはゲストOSと連携してShutdownなどを行えます。実際にShutdownを選び、タスクが正常終了してVMがStoppedになることを確認します。その後Startし、再びUbuntuが起動することを確認します。
Stopは物理PCの電源を突然切るような操作で、書き込み途中のデータやファイルシステムを損傷する可能性があります。Resetも物理リセットボタンに近い強制操作です。Shutdownできないから、とりあえず押すボタンではありません。
停止条件：Shutdownタスクが失敗する、一定時間待ってもStoppedにならない場合はStopやResetを続けて押さず、Consoleとタスクログで停止を妨げている処理を確認します。
手順6：noVNC ConsoleとSSHの役割を確認する
Proxmox Web UIで対象VMのConsoleを開き、noVNCでUbuntuのログイン画面が表示されることを確認します。noVNC Consoleは、物理サーバーへキーボードと画面を直接つないだ状態に近い管理・復旧経路です。
| 接続方法 | 向いている用途 |
|---|---|
| noVNC Console | SSH設定前、ネットワーク障害、起動メッセージ、復旧作業 |
| SSH | 通常のコマンド操作、更新、設定編集、ログ確認 |
日常管理はUbuntu ServerへSSH鍵認証で安全に接続する方法を基本にします。SSHがつながらないときにConsoleへ戻れることが、VM運用の強みです。
ProxmoxにはほかのConsole方式もありますが、今回はnoVNCだけを扱います。noVNCが開かないからといって、Display、Serial Port、GRUB設定を同時に変更しません。
停止条件：Consoleが開かない、画面が固まる、ログイン画面が出ない場合は別の障害として切り分けます。SSHだけが使える状態でも、Console設定を推測で変更しません。
手順7：停止中VMのスナップショットを作成して確認する
今回は一貫性を分かりやすくするため、VMをShutdownしてStoppedになった状態でスナップショットを作ります。対象VMのSnapshots → Take Snapshotを開き、名前を例として after-qemu-guest-agent、説明に作成目的と日付を入れます。VMのRAMは含めません。
作成後、Snapshots一覧に名前・日時・説明が表示され、タスクログがOKであることを確認します。その後VMをStartし、Ubuntuが正常起動することまで確認します。
Snapshot ≠ Backup
スナップショットは同じストレージ上の短期チェックポイントです。元ストレージの故障やVM全体の消失に備える別保存先の復旧用コピーではありません。ProxmoxのVMバックアップはvzdumpやProxmox Backup Serverを使う別機能です。
Rollbackは今回実行しない
RollbackはVM設定とディスクをスナップショット作成時点へ戻す操作です。作成後に加えた変更は失われる可能性があります。復元対象・失われる変更・バックアップ・停止時間を整理した専用の復旧テストとして扱います。
Deleteも今回実行しない
Deleteはスナップショットを削除する操作です。ストレージ処理が完了するまで時間がかかる場合があり、作成直後に確認目的で消す必要はありません。
Snapshotsが利用できない場合はストレージ形式やディスク構成が対応していない可能性があります。記事に合わせるためストレージ構成を変更せず、作成を見送ります。
VM Snapshots — Proxmox VE公式 / Backup and Restore — Proxmox VE公式
停止条件：VMがStoppedにならない、Snapshot操作が利用できない、ストレージ容量が不足、タスクがエラーになる場合は作成を繰り返しません。Rollback・Deleteは押しません。
Ubuntu VM安全運用チェックリスト
- 1：VMが正常で、今回実行しない強制・復元操作を確認した
- 2：Ubuntuへ公式パッケージのqemu-guest-agentを導入した
- 3：正常終了後にProxmox側のQEMU Guest Agentを有効にした
- 4：完全停止後にStartし、Ubuntu側activeとProxmox側の応答を確認した
- 5：Start・Shutdownを使い、Stop・Resetを通常操作に使わないと確認した
- 6：noVNC Consoleを開き、SSHとの役割の違いを確認した
- 7：停止中VMでSnapshotを1個作成し、Rollback・Deleteせず一覧を確認した
まとめ
Ubuntu VMの日常運用でまず身につけたいのは、Guest AgentでProxmoxとUbuntuを連携させ、通常はStartとShutdownを使い、障害時にConsoleへ戻れる状態を保つことです。
スナップショットは変更前の短期チェックポイントとして便利ですが、バックアップではありません。今回は作成と存在確認までに留め、Rollback・Deleteを安全確認なしで実行しない境界を作りました。
次回は、ProxmoxのVMを本当に復旧できるようにするため、VMバックアップの保存先・モード・復元先を確認し、スナップショットとの違いを実践で整理します。
コメント