内容をスキップ
ktcsp.net
  • ホーム
  • ドキュメント拡大
    • 仮想基盤の構築拡大
      • 仮想基盤について
      • HCI仮想基盤(XCP-ng+XOSTOR)
      • HCI仮想基盤(ProxmoxVE+Ceph)
    • サーバーの構築拡大
      • 基本サーバー(Rocky Linux)
      • Mailサーバー(Postfix/Dovecot)
      • Webサーバー(Apache)
      • リバースプロキシサーバー(Nginx)
      • 内向DNSサーバー(Dnsmasq)
      • Backupサーバー(Storware)
      • 監視サーバー(Zabbix)
    • ホームページの構築拡大
      • WordPressの導入と設定
      • ホームページの作成(Kadence)
      • ドキュメントページの作成(BetterDocs)
      • ギャラリーページの作成(NextGen Gallery)
      • 問い合わせページの作成(WPForms)
    • オンラインストレージの構築拡大
      • Nextcloudの導入と設定
  • ギャラリー拡大
    • ヨーロッパ拡大
      • イタリア
      • スペイン
      • ポルトガル
      • ギリシャ
      • フランス
      • イギリス
    • アジア拡大
      • 中国
      • 日本
    • その他拡大
      • オーストラリア
      • ハワイ
  • お知らせ
  • お問い合わせ
ktcsp.net

仮想基盤の構築

  • 仮想基盤について
    • まずは自己紹介から
    • システム環境について
    • HA仮想環境について
  • HCI仮想基盤(XCP-ng+XOSTOR)
    • XCP-ngの導入
    • Xen Orchestraの導入設定
    • XCP-ngの環境設定
    • HCI仮想環境の構築
    • 仮想マシンの操作方法
  • HCI仮想基盤(ProxmoxVE+Ceph)
    • ProxmoxVEの導入設定
    • クラスタ環境の構築
    • HCI仮想環境の構築
    • 仮想マシン・コンテナの操作方法

サーバーの構築

  • 基本サーバー(Rocky Linux)
    • 準備中
  • Mailサーバー(Postfix/Dovecot)
    • 準備中
  • Webサーバー(Apache)
    • 準備中
  • リバースプロキシサーバー(Nginx)
    • 準備中
  • 内向DNSサーバー(Dnsmasq)
    • 準備中
  • NFSサーバー
    • 準備中
  • Backupサーバー(Storware)
    • 準備中
  • 監視サーバー(Zabbix)
    • 準備中

ホームページの構築

  • WordPressの導入と設定
    • 準備中
  • ホームページの作成(Kadence)
    • 準備中
  • ドキュメントページの作成(BetterDocs)
    • 準備中
  • ギャラリーページの作成(NextGen Gallery)
    • 準備中
  • 問い合わせページの作成(WPForms)
    • 準備中

オンラインストレージの構築

  • Nextcloudの導入と設定
    • 準備中
View Categories
  • ドキュメント
  • 仮想基盤の構築
  • HCI仮想基盤(ProxmoxVE+Ceph)

仮想マシン・コンテナの操作方法

当ページでは、仮想マシンやコンテナを操作する方法(作成・複製・削除など)を紹介します。

 

1. 仮想マシンとコンテナの比較 #

まずはPVEで作成可能な仮想マシン(VM)とLinuxコンテナ(LXC)の違いについてまとめます。既に違いをご存じの方やコンテナ自体に興味のない方は読み飛ばしてください。

VM:物理コンピュータ(ホスト)上で擬似的に再現された仮想コンピュータ
LXC:LinuxホストOSのカーネルを共有しつつ独立して稼働するLinux環境

①仮想マシンとLinuxコンテナの比較(*)

比較項目仮想マシン(VM)Linuxコンテナ(LXC)
起動時間遅い(数十秒)爆速(数秒)
オーバーヘッド大(HWエミュレーションあり)小(HWエミュレーションなし)
メモリ使用量大(1GB程度~)小(数MB程度~)
ディスク使用量大(2GB程度~)小(500MB程度~)
セキュリティ(隔離性)高(ホストと分離)低(ホストと不可分)
稼働可能OS多(Windows, Linux, BSD等)少(Linuxのみ)
稼働可能アプリ無制限限定的(ホストカーネルに依存)
ライブマイグレーション可不可

* 上記の比較表は主にこちらのページを参考にさせていただきました(感謝)

②環境別の選択基準
安全性と保守性が極めて重要で高速性は物理ホストで担保できる本番環境なら仮想マシン、高速性が極めて重要で安全性と保守性は運用でカバーできるテスト/開発環境ならコンテナが良いと一般的に言われています。

③環境別の利用比率(2026年推計)by Google AI(*)
利用実態を掴む上でDockerの存在は無視できないため、コンテナについてはDockerとLXCに分け、DockerについてはVM上で稼働かベアメタルで稼働かを更に分けて確認しました。

環境仮想マシン
コンテナ(VM上で稼働するものも含む)
DockerLXC
VM上で稼働ベアメタル
本番環境(サービス提供)60%30%5%5%
テスト/開発環境10%70%15%5%

* Google AI によって確認した数値のため、あくまでも参考として捉えてください。

▼上記の推計から見て取れること

  • Linuxコンテナ(LXC)の利用比率は非常に小さいが、環境問わず一定程度の利用はある
  • コンテナの利用比率は、本番環境でも4割、テスト/開発環境では驚異の9割と非常に高いが、VMを介さない純粋なコンテナの比率でみると本番環境で1割、テスト/開発環境でも2割と低い
  • コンテナが稼働している分も含めた仮想マシンの利用比率は、本番環境で9割、テスト/開発環境でも8割と圧倒的である

以上より、現時点におけるコンテナは仮想マシンとパイを争う存在ではなく、安全安心な仮想マシンにテスト/開発やサービスデプロイの高速化という価値を付加する存在なのだと個人的に捉えています。余談ですが、Proxmoxでベアメタルのコンテナも使えるんだとウキウキしていた私としてはLXCの利用制限や利用比率の低さに少々へこんでいるところです。

 

2. 仮想マシン(VM)の作成 #

 

1)ISOイメージのアップロード #

URLを指定してISOイメージをWebからダウンロードすることもできますが、ここではPCからISOイメージをアップロードする方法を紹介します。

CephFSストレージにアップロードする場合でも、ローカルストレージ(/var/tmp)に一時的に格納され、CephFSストレージにコピーされる仕様になっているため、ローカルストレージの空き容量には注意してください。また、アップロードが正常に終了した場合はローカルストレージに保管された一時ファイルは自動的に削除されますが、異常終了した場合は削除されない場合がありますので、その際は手動で削除する必要があります。

左メニューよりいずれかのホストの「CephFSストレージ」>「ISOイメージ」を選択します。
> 左上の「アップロード」ボタンをクリックします。

Webからダウンロードする場合は「URLからダウンロード」をクリックして進めます。

ポップアップ画面にて「ファイルを選択」ボタンをクリックします。

PCに保存済みのISOイメージファイルを選択し、「開く」をクリックます。

内容を確認の上、「アップロード」ボタンをクリックします。

アップロードが完了するまでしばらく待機します。

アップロードが完了するとタスクビューアが表示されますが、ローカル(/var/tmp)にアップされたISOファイルをCephFSにコピーするタスクが残ってますのでそのまましばらく待機します。

タスクビューアにて「TASK OK」と表示されたらビューアを「X閉じ」します。

ISOイメージファイルがCephFSストレージに登録されたことを確認します。

他のホストからもISOイメージファイルが参照できることを確認します。

 

2)仮想マシン(VM)の作成 #

右上の「VMを作成」ボタンをクリックします。

①全般設定
稼働ホストと仮想マシン名を入力し、「次へ」ボタンをクリックします。

▼設定情報
ノード:仮想マシンを稼働させるホストをプルダウンから選択(必須)
VM ID:自動採番される識別番号(100以上の未使用番号なら変更も可)
名前:仮想マシンの識別名(必須)
HAに追加:HA対象の仮想マシンにする場合はチェック(後から変更も可)
リソースプール:既存のプールに追加する場合はプルダウンから選択(後から追加も可)

リソースプールとは
リソース(仮想マシン/コンテナ/ストレージ)、ユーザー(またはグループ)、アクセス権をセットにした権限管理表のようなものです。管理者はプールの作成によりユーザーごとに利用可能なリソースと権限を設定することができます。プール作成済みであればいつでも(作成時でも作成後でも)仮想マシンをプールに追加することができます。

②OS設定
ラジオボタン「CD/DVDイメージファイル(iso)を使用」を選択
> その他必要情報を選択し、「次へ」ボタンをクリックします。

▼必要情報
ストレージ:ISOイメージファイルをアップロードしたストレージ(cephfs / local)を選択
ISOイメージ:アップロード済みのISOイメージファイル(xxxxx.iso)を選択
種別:OSの種類(Linux / Windows / Solaris / Other)を選択
バージョン:カーネルのバージョン(2.4 Kernel / 6.x – 2.6 Kernel)を選択

③システム設定
BIOSを規定の「SeaBIOS」から「OVMF (UEFI)」に変更します。
> EFIストレージとしてCephストレージ(rbd)を選択します。
> Qemuエージェントにチェックを入れ、「次へ」ボタンをクリックします。

UEFIついて
UEFIを選択した場合、EFIストレージ(管理区画を作成するストレージ)を指定する必要があります。ローカルストレージ(local-lvm)を選択してしまうとライブマイグレーションやHAの対象外となってしまうため、必ずCephストレージ(rbd)を選択します。

Qemuエージェントについて
ホストがゲストOSを管理するために必要となるゲストエージェントです。仮想マシンにこのエージェントを導入するには設定にチェックを入れ有効化しておく必要があります。

TPM追加について
ゲストがWindowsの場合は追加が必須となります。追加する場合、TPMストレージ(暗号鍵を保存するストレージ)とTPMバージョン(1.2 / 2.0)の指定が必要で、Windows11の場合は、TPM2.0を選択する必要があります。

④ディスク設定
Cephストレージ(rbd)を選択し、必要なディスク容量を指定します。
>「中止」と「SSDエミュレーション」にチェックを入れ、「次へ」ボタンをクリックします。

中止(Discard)について
この設定を有効化することで、ゲストOSは「ファイルの削除で使用不可となったデータ領域」を破棄(解放)できるようになり、仮想DISKの肥大化の防止、引いてはCephストレージの利用可能領域の最大化に繋がります。
注1)Linuxで破棄を自動化するには、後述するゲストOS側での追加設定が必要です。
注2)Windowsで破棄を実行するには、SSDエミュレーションの有効化が必要です。

SSDエミュレーションについて
仮想DISKはSSDであるとゲストに伝える設定です。無効のままだとゲストは仮想DISKをHDDとして捉えデフラグを走らせてしまうため、物理DISKがSSDの場合は必ず有効化します。また、分散ストレージではデフラグの意味はなくゲストのリソースを無駄遣いするだけのため、Cephストレージの場合は物理DISKがHDDでも有効化します。

⑤CPU設定
ソケット数/コア数/種別を指定し、「次へ」ボタンをクリックします。
注)種別の選択は非常に重要なため下段のヒントを必ず参照してください。

種別(Type)について(重要)
CPUが正しく理解できる命令をゲストOSが送れるようにするために重要な設定で、選択を誤るとOSがカーネルパニックを起こして起動しなくなるため注意が必要です。

①すべてのホストが全く同じCPUを搭載している場合
ホストのCPU機能をVMがフル活用できるようにする「host」を選択します。
これにより、VMには最大のCPUパフォーマンスが提供されることになります。

②CPUの世代が異なるホストが混在している場合
最も世代が古いCPUと同じモデル(Intel Haswell、AMD EPYC等)を選択します。
これにより、新CPU搭載ホストから旧CPU搭載ホストへライブマイグレーションする際、旧CPUでもOSの命令が正しく理解できるため移動に失敗することがなくなります。

③CPUメーカーが異なるホストが混在している場合
最も世代が古いCPUに対応した仮想CPU(QEMU x86-64-v2, v3等)を選択します。
これにより、メーカー間ならびに世代間のギャップがなくなり、②と同様にライブマイグレーションに失敗することがなくなります。

注)CPUモデルや仮想CPUを選択する際の注意点
最も世代が古いCPUのマイクロアーキテクチャレベル(x86-64-v2, v3等)がOSのサポートレベル(RHEL9はv2以上/10はv3以上)未満だと全ホストでVMが稼働しなくなるため、OSサポートレベルまで上げる必要があります。

⑥メモリ設定
メモリ容量とBallooningの有効・無効を指定し、「次へ」ボタンをクリックします。

Ballooningとは
仮想マシンで未使用のメモリ容量を解放(ホストに返還)することで仮想マシン間でメモリのリソースを効率的に分け合えるようにする機能です。有効にすると、仮想マシンに最低限占有させたい最小メモリ容量が指定できます。無効にすると、仮想マシンは未使用メモリ容量を解放せず指定したメモリ容量を占有します。

⑦ネットワーク設定
プライマリNICのブリッジ(vmbr0)を選択し、「次へ」ボタンをクリックします。

⑧設定確認
これまでに設定した内容を確認し、問題なければ「完了」ボタンをクリックします。
※修正したい場合はタブを切り替えて設定を変更することができます。

左メニューにて仮想マシンが作成されていることを確認します。

左メニューよりいずれかのホストの「RBDストレージ」>「VMディスク」を選択します。
> 仮想マシンのディスクイメージ(VDI)が追加されていることを確認します。

追加されるディスクイメージについて
システム設定で BIOSを「SeaBIOS」にしていた場合は vm-[vmid]-disk-0(OS領域)のみ表示され、「OVMF (UEFI)」にしていた場合は vm-[vmid]-disk-0(EFIディスク管理領域)と vm-[vmid]-disk-1(OS領域)が表示されます。

左メニューより「仮想マシン名」 >「コンソール」を選択します。
> 上部の「開始」または中央の「Start Now」をクリックして仮想マシンを起動させます。

指定したISOファイルが読み込まれ、OSインストーラーが起動するまでしばらく待機します。
> インストーラーが起動したら、「Install OS名」を選択し、エンターキーで決定します。
> OSインストール開始画面が表示されるまでしばらく待機します。

OSインストール開始画面が表示されたら、OSのインストールを進めてゆきます。
(OSのインストール手順はここでは割愛させてもらいます)

インストール完了後の再起動を経て、仮想マシンが起動したことを確認します。

block dm-0: the capability attribute has been deprecatedという警告が出ますが、実害はないため無視して構いません。この警告はkernelの改変にOSが対応しきれないため表示される警告のため、OSの対応を待つしかありません。

左メニューより「データセンター」>「サマリー」を選択します。
> 稼働中の仮想マシンが1台増えていることを確認します。

左メニューより「仮想マシン」>「ハードウェア」を選択します。
> CD/DVDドライブを選択し、上部の「編集」ボタンをクリックします。

CD/DVDイメージファイル(ISO)を使用するから、メディアを使用しないに変更し、
仮想CD/DVDドライブからISOイメージファイルを取り外します。

CD/DVDドライブの内容が「none」という表示に変わったことを確認します。

ISOファイルを仮想CD/DVDから取り外しておかないと、ストレージからISOファイルを削除した後に仮想マシンをマイグレーションさせようとすると、あるはずのISOファイルがないといった警告が出て移動に失敗します。

 

3)ゲストエージェントの導入 #

仮想マシンにゲストエージェント(Qemuエージェント)をインストールすることで、PVEホストが仮想マシンのOS情報を取得したり、OSを直接操作したりできるようになります。

▼エージェント有無の主な違い

機能エージェントなしエージェントあり
管理画面にゲストOS情報を表示不可可(但しIPアドレスのみ)
管理画面からVMシャットダウン可(電源ボタン長押しと同じ)可(ゲストOSにshutdownコマンドを指示)(*1)
管理画面からVM再起動不可可(ゲストOSにrebootコマンドを指示)
より安全なバックアップを実行不可(通常バックアップ)可(直前にファイルシステムをフリーズ)(*2)
ホストのCLIからゲストOS情報を取得不可可(qm guest cmd [vmid] get-xxxx)(*3)
ホストのCLIからゲストOSコマンドを操作不可可(qm guest exec [vmid] -- [OSコマンド])(*4)
ホストのCLIからユーザーパスワードを変更不可可(qm guest passwd [vmid] [OSユーザー名])(*5)
  • コマンドからきちんとシャットダウンを行うため、VMを安全に停止できるようになります。
  • スナップショット前にファイルシステムを一瞬フリーズ(静止)させ、確実にブレのないスナップショットを撮ります。
  • qm guest cmd のオプションにはOS情報を取得する「get-xxxx」以外にもいくつかあります。
  • ホストからゲストOSに管理者権限(パスワード不要)で直接アクセスし、ゲストOSを完全に操作できてしまうことから、 セキュリティの観点よりQemuエージェントはこのコマンドの実行をデフォルトで禁止(ブロック)しています。ゲストOS側でQemuエージェントの設定ファイル(/etc/sysconfig/qemu-ga)を編集し、ブロックを解除(--block-rpcsオプションからguest-execを削除)することもできますが、あまりお勧めはできません。
  • このコマンドは、古いパスワードを知らなくても新しいパスワードが設定できrootパスワードも変更できるため、取扱には十分注意してください。

左メニューより「仮想マシン名」 >「サマリー」を選択します。
> IPアドレス欄に「ゲストエージェントが未実行」と表示されていることを確認します。

左メニューより「仮想マシン名」 >「オプション」を選択します。
> QEMU Guest Agentが「有効」になっていることを確認します。

QEMU Guest Agentが「無効」になっていた場合は、「QEMU Guest Agent」をダブルクリックし、設定画面を開き「QEMU Guest Agentを使用」にチェックを入れ設定を変更します。

左メニューより「仮想マシン名」 >「コンソール」を選択します。
> コンソール画面から管理者ユーザーとパスワードでゲストOSにログインします。

コマンドラインからゲストエージェントをインストールします。

▼RHEL系OS(RHEL/CentOS/Rocky Linux/AlmaLinux/Oracle Linux等)の場合

# dnf install qemu-guest-agent               ← qemu-guest-agentを導入
# systemctl enable --now qemu-guest-agent ← 自動起動を有効化&起動
# systemctl is-enabled qemu-guest-agent ← 自動起動設定を確認
# systemctl status qemu-guest-agent ← 起動状態を確認

▼Debian系OS(Debian/Ubuntu等)の場合

# apt update                                 ← パッケージリストを更新
# apt install qemu-guest-agent     ← qemu-guest-agentを導入
# systemctl enable --now qemu-guest-agent ← 自動起動を有効化&起動
# systemctl is-enabled qemu-guest-agent ← 自動起動設定を確認
# systemctl status qemu-guest-agent ← 起動状態を確認

左メニューより「仮想マシン名」 >「サマリー」を選択します。
> IPアドレス欄に「IPアドレス」が表示されたことを確認します。

仮想マシンが稼働しているホストのCLIでゲストOSの情報が取得できることを確認します。
注)仮想マシンが稼働していないホストではゲストOSの情報は取得できません。

# qm guest cmd [vmid] get-osinfo  ← vmidは仮想マシンの3桁の数字を指定
{
   "id" : "rocky",
   "kernel-release" : "6.12.0-124.8.1.el10_1.x86_64",
   "kernel-version" : "#1 SMP PREEMPT_DYNAMIC Tue Nov 11 22:54:28 UTC 2025",
   "machine" : "x86_64",
   "name" : "Rocky Linux",
   "pretty-name" : "Rocky Linux 10.1 (Red Quartz)",
   "version" : "10.1 (Red Quartz)",
   "version-id" : "10.1"
} 

 

4)使用不可領域の破棄設定(Linuxのみ) #

ファイル削除(インデックス削除)で不要となったデータ領域を破棄(解放)し、DISKの空き容量を増やす処理を自動化します。

Linuxには使用不可領域を破棄する機能(fstrim)が標準装備されており、この機能を週次で自動実行するためのSytemd Timer(fstrim.timer)も用意されています。

①破棄設定の確認

まずはゲストOSによる破棄の実行がPVEで許可されているかを確認します。

左メニューより「仮想マシン名」 >「ハードウェア」を選択します。
>ハードウェア(scsi0)の内容で「discard」が有効(on)になっていることを確認します。

discardが「無効」になっていた場合は、「ハードウェア(scsi0)」をダブルクリックし、設定画面を開き「中止(Discard)」にチェックを入れ設定を変更します。

②手動による破棄の動作確認

自動実行設定を行う前に念のため手動実行で破棄されるか動作確認を行います。

テスト前のDISK使用量を確認しておきます。

▼ホスト側での確認

# rbd du -p Pool01
NAME PROVISIONED USED
vm-100-disk-0 1 MiB 1 MiB
vm-100-disk-1 15 GiB 1.7 GiB  ← VM Diskイメージの使用量確認
<TOTAL> 15 GiB 1.7 GiB

▼ゲスト側での確認

# df -h /
ファイルシス サイズ 使用 残り 使用% マウント位置
/dev/mapper/rl_base-root 9.4G 1.4G 8.1G 15% /  ← /領域の使用量確認

ゲストOS側で1GBのテストファイルを作成します。
> 作成が完了するまで数十秒ほど待機します。

# dd if=/dev/urandom of=/root/testfile bs=1M count=1K	← 1GBのテストファイルを作成

テストファイル作成後のDISK使用量を確認します。

▼ホスト側での確認

# rbd du -p Pool01
NAME PROVISIONED USED
vm-100-disk-0 1 MiB 1 MiB
vm-100-disk-1 15 GiB 2.7 GiB  ← 使用量が増えていることを確認量
<TOTAL> 15 GiB 2.7 GiB

▼ゲスト側での確認

# df -h /
ファイルシス サイズ 使用 残り 使用% マウント位置
/dev/mapper/rl_base-root 9.4G 2.4G 7.1G 26% /  ← 使用量が増えていることを確認

ゲストOS側でテストファイルを削除します。

# rm -f /root/testfile  ← テストファイルを削除

テストファイル削除後のDISK使用量を確認し、ゲスト側では使用量が減っているにも関わらずホスト側では減っていないことを確認します。この減っていない容量がストレージで使用できなくなってしまったデータ領域(無駄な領域)の容量となります。

▼ホスト側での確認

# rbd du -p Pool01
NAME PROVISIONED USED
vm-100-disk-0 1 MiB 1 MiB
vm-100-disk-1 15 GiB 2.7 GiB  ← 使用量が減っていない(使用不可領域が解放されていない)ことを確認
<TOTAL> 15 GiB 2.7 GiB

▼ゲスト側での確認

# df -h /
ファイルシス サイズ 使用 残り 使用% マウント位置
/dev/mapper/rl_base-root 9.4G 1.4G 8.1G 15% /  ← 使用量が減っていることを確認

ゲストOS側でストレージの使用不可領域を破棄(解放)します。

# fstrim -av  ← 使用不可領域の破棄(解放)

正確には、ゲストOS側が直接破棄するのではなく、ゲストOS側でこの領域はもう使用していませんとホストに伝え、ホストがその領域を破棄する流れとなります。

ホスト側でDISK使用量を確認します。

# rbd du -p Pool01
NAME PROVISIONED USED
vm-100-disk-0 1 MiB 1 MiB
vm-100-disk-1 15 GiB 1.7 GiB  ← 使用量が減っている(使用不可領域が解放されている)ことを確認
<TOTAL> 15 GiB 1.7 GiB

③破棄の自動実行設定

手動破棄テストで動作確認がとれたら自動実行させる設定を行います。

ゲストOS側でfstrimコマンドを自動実行するSystemd Timer(fstirm.timer)を有効にします。
※これにより、使用不可領域の破棄が週次で自動的に実行されるようになります。

# systemctl enable --now fstrim.timer ← fstrim.timerの自動起動を有効化&起動
# systemctl is-enabled fstrim.timer ← 自動起動設定を確認
# systemctl status fstrim.timer ← 起動状態を確認

 

5)マイグレーションのテスト #

仮想マシンのメタデータとディスクイメージを各ホストが常に共有しているため、仮想マシンを停止させることなく別のホストへ移動(ライブマイグレーション)させることができます。

ライブマイグレーションを実現するための特別な設定は必要ありません。

★無停止での移動を目視確認するため事前にSSH接続しターミナルを開いておきます。

VMのコンソール画面を表示させたまま、右上の「マイグレート」ボタンをクリックします。

ターゲットノード(移行先ホスト)を選択し、「マイグレート」ボタンをクリックします。

タスクビューアが表示されますので完了するまでしばらく(数秒程度)待機します。

タスクビューアに「TASK OK」と表示されたらビューアを「X閉じ」します。

仮想マシンが移行先ホストに移動したことを確認します。
コンソール画面が切断されずそのまま表示されている(再起動していない)ことを確認します。

★開いていたSSH接続ターミナルが切断されていないことで無停止での移動を確認します。

 


■トラブルシューティング

マイグレーション後に以下のような「clocksource」関連の警告が出力されることがあります。

システムログにも以下のように同じ警告ログが記録されます。

# cat /var/log/messages | grep clocksource
----------------------------------------------------------------------------------------------------------------------------------------------------
May 4 17:23:47 base kernel: clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large:
May 4 17:23:47 base kernel: clocksource: 'kvm-clock' wd_nsec: 496021033 wd_now: 55f046eba044 wd_last: 55f0295af21b mask: ffffffffffffffff
May 4 17:23:47 base kernel: clocksource: 'tsc' cs_nsec: 499427844 cs_now: f7dc8de2c003 cs_last: f7dc37c1e228 mask: ffffffffffffffff
May 4 17:23:47 base kernel: clocksource: Clocksource 'tsc' skewed 3406811 ns (3 ms) over watchdog 'kvm-clock' interval of 496021033 ns (496 ms)
May 4 17:23:47 base kernel: clocksource: 'kvm-clock' (not 'tsc') is current clocksource.
May 4 17:23:47 base kernel: tsc: Marking TSC unstable due to clocksource watchdog
----------------------------------------------------------------------------------------------------------------------------------------------------

これはVM内の時計(TSC)とホスト側の時計にズレが生じると出力される警告で、ライブマイグレーション時のほんの僅かな時間のズレでも出力されることがあります。1度出力されれば以降は出力されませんが、再起動後の1回目のマイグレーション時に毎回出力される場合もあります。この警告が煩わしい場合は、出力されないよう設定することができます。具体的には、TSCを信頼できる時計としてGRUBに登録し、僅かな時計のズレは大目にみる設定に変更します。

▼警告を出力させない方法

# grubby --update-kernel=ALL --args="tsc=reliable"  ← TSC時計を信頼できる時計としてGRUBに登録
# grubby --info=DEFAULT | grep args
args="・・・・・・・・・・・・・・・・・・ tsc=reliable"  ← 予約登録されたことを確認
# reboot  ← 登録を反映させるため再起動

# cat /proc/cmdline
BOOT_IMAGE=・・・・・・・・・・・・・・・ tsc=reliable ← 追加登録されたことを確認

これで再起動後のマイグレーションの度に警告が表示されることはなくなります。


以上で仮想マシンの作成は完了です。

 

3. コンテナ(CT)の作成 #

 

1)テンプレートのダウンロード #

コンテナ用のテンプレートをChepFSストレージにダウンロードします。
ダウンロード済みのテンプレートをPCからアップロードすることや、URLを指定して最新のテンプレートをWebから直接ダウンロードすることもできますが、ここではPVEで予め用意されているテンプレートをダウンロードする方法を紹介します。

左メニューよりいずれかのホストの「CephFSストレージ」>「CTテンプレート」を選択します。
> 上部の「テンプレート」ボタンをクリックします。

  • PCからアップロードする場合は「アップロード」をクリックして進めます。
  • Webからダウンロードする場合は「URLからダウンロード」をクリックして進めます。
  • ダウンロードする際はこちらのページから OS > バージョン > amd64 > defauld > 日付と辿り、ファイル一覧の中から「rootfs.tar.xz」を選択します。
    例)https://images.linuxcontainers.org/images/rockylinux/10/amd64/default/20260505_04%3A38/rootfs.tar.xz

一覧から導入したいOSのテンプレートを選択し、「ダウンロード」をクリックします。

タスクビューアが表示されますので「TASK OK」と表示されたらビューアを「X閉じ」します。

選択したOSのテンプレートがCephFSストレージに登録されたことを確認します。

 

2)LXCコンテナの作成 #

右上の「CTを作成」ボタンをクリックします。

①全般設定
稼働ホスト/ホスト名/rootパスワードを入力し、「次へ」ボタンをクリックします。

▼設定情報
ノード:コンテナを稼働させるホストをプルダウンから選択(必須)
CT ID:自動採番される識別番号(100以上の未使用番号なら変更も可)
ホスト名:コンテナのホスト名を設定(空欄も可だがほぼ必須)
非特権コンテナ:特権コンテナにする場合はチェックを外す(後から変更不可)
ネスト:コンテナ上でLXCやDockerを動かす場合はチェック(後から変更も可)
HAに追加:HA対象のコンテナにする場合はチェック(後から変更も可)
リソースプール:既存のプールに追加する場合はプルダウンから選択(後から追加も可)
パスワード:コンテナのrootパスワードを設定(必須)
SSH公開鍵:公開鍵認証でSSH接続する場合は登録(管理画面では後から登録は不可)

ホスト名について(重要)
空欄だとPVEが勝手に名前を決めるため、設定は必須と考えてください。管理画面で後から簡単に変更もできますが、この名前はPVE管理上の単なる識別名ではなく、仮想マシンでいうところのゲストOSのホスト名に当たるため、安易に変更すると名前解決で支障をきたす危険性がありますので変更の際は十分注意してください。

非特権コンテナについて
特権/非特権の違いを理解した上でどうしても特権にする必要があるという場合以外は、非特権のまま進めます。後から変更はできませんが、コンテナをバックアップ→リストアすればリストア時に権限を設定し直すことはできます。

リソースプールとは
リソース(仮想マシン/コンテナ/ストレージ)、ユーザー(またはグループ)、アクセス権をセットにした権限管理表のようなものです。管理者はプールの作成によりユーザーごとに利用可能なリソースと権限を設定することができます。プール作成済みであればいつでも(作成時でも作成後でも)仮想マシンをプールに追加することができます。

②テンプレート設定
アップロード済みのテンプレートを選択し、「次へ」ボタンをクリックします。

▼必要情報
ストレージ:テンプレートをダウンロードしたストレージ(cephfs / local)を選択
テンプレート:アップロード済みのテンプレートファイル(xxxxx.tar.xz)を選択

③ディスク設定
Cephストレージ(rbd)を選択 > ディスク容量を指定 >「次へ」ボタンをクリックします。

④CPU設定
コア数を指定し、「次へ」ボタンをクリックします。

⑤メモリ設定
メモリ容量とスワップ容量を指定し、「次へ」ボタンをクリックします。

⑥ネットワーク設定
プライマリNICのブリッジ(vmbr0)を選択します。
> IPアドレス(CIDR形式)とゲートウェイを指定し、「次へ」ボタンをクリックします。

⑦DNS設定
必要に応じてDNS検索ドメインとDNSサーバーIPを指定し、「次へ」ボタンをクリックします。

基本的には「ホスト設定を使用」のままでOKです。コンテナ同士を独自のドメイン名で通信させたい、独自の名前解決をしたいといった場合にのみ指定します。

⑧設定確認
これまでに設定した内容を確認し、問題なければ「完了」ボタンをクリックします。
※修正したい場合はタブを切り替えて設定を変更することができます。

タスクビューアが表示されますので作成が完了するまでしばらく(十秒程)待機します。

タスクビューアに「TASK OK」と表示されたらビューアを「X閉じ」します。

左メニューにてコンテナが作成されていることを確認します。

左メニューよりいずれかのホストの「RBDストレージ」>「CTボリューム」を選択します。
> コンテナのディスクイメージ(VDI)が追加されていることを確認します。

左メニューより「コンテナ名」 >「コンソール」を選択します。
> 上部の「開始」ボタンをクリックし、コンテナを起動させます。

以前(PVE 8.0.x)までは画面中央に「Start Now」ボタンが表示され、このボタンからでもコンテナを起動できたのですが、現時点(9.1.x)では表示されないようです。

ものの数秒でコンテナが起動したことを確認します。

左メニューより「データセンター」>「サマリー」を選択します。
> 稼働中のコンテナが1台増えていることを確認します。

 

3)SSHサーバーの導入 #

LXCコンテナを導入しただけではSSH接続ができないため、SSHサーバーを導入します。

左メニューより「コンテナ名」 >「コンソール」を選択します。
> コンソール画面からrootユーザーとパスワードでコンテナにログインします。

コマンドラインからSSHサーバー(openssh-server)をインストールします。

▼RHEL系OS(RHEL/CentOS/Rocky Linux/AlmaLinux/Oracle Linux等)の場合

# dnf install openssh-server    ← SSHサーバーを導入

▼Debian系OS(Debian/Ubuntu等)の場合

# apt update                    ← パッケージリストを更新
# apt install openssh-server    ← SSHサーバーを導入

デフォルトでは「rootによるパスワード認証」は禁止されています。
rootパスワードでSSH接続する場合は設定を「禁止」から「許可」に変更します。

# cd /etc/ssh/sshd_config.d/  ← SSHサーバー用の追加設定ディレクトリに移動(注)
# vi 01-permitrootlogin.conf ← 追加設定ファイルを新規作成(注)
------------------------------------------------------------------------
PermitRootLogin yes  ← 許可設定を書込み
------------------------------------------------------------------------
  • SSHクライアント用のディレクトリ(ssh_config.d)もあるため、必ずサーバー用のディレクトリ(sshd_config.d)内に追加設定ファイルを作成してください。
  • ファイル名は分かりやすければ何でも構いませんが、SSHサーバーにこの設定を一番最初に読み込ませる必要があるため、先頭番号は必ず「01」にしてください。

SSHサーバーの自動起動を有効化し起動させます。

▼RHEL系OS(RHEL/CentOS/Rocky Linux/AlmaLinux/Oracle Linux等)の場合

# systemctl enable --now sshd    ← 自動起動を有効化&起動
# systemctl is-enabled sshd ← 自動起動設定を確認
# systemctl status sshd ← 起動状態を確認

▼Debian系OS(Debian/Ubuntu等)の場合

# systemctl enable --now ssh    ← 自動起動を有効化&起動
# systemctl is-enabled ssh ← 自動起動設定を確認
# systemctl status ssh ← 起動状態を確認

Debian系でのサービス名は「sshd」ではなく「ssh」なので注意してください。

ターミナルソフトを使ってPCからコンテナにrootパスワードでSSH接続できるか確認します。

 

4)マイグレーションのテスト #

コンテナはホストのOSを利用しているためライブマイグレーションはできません。コンテナが起動中でもマイグレーションは行えますが、コンテナは自動シャットダウンされ、移動が完了した後に自動起動される仕組みとなっています。

コンテナは瞬時に停止・起動するため、注意深く観察していないとまるでライブマイグレーションされたかのように見えてしまいますが、稼働していたJOBはシャットダウンにより強制終了されるため注意が必要です。

★移動前の停止を目視確認するため事前にSSH接続しターミナルを開いておきます。

左メニューより「コンテナ名」を選択し、右上の「マイグレート」ボタンをクリックします。

ターゲットノード(移行先ホスト)を選択し、「マイグレート」ボタンをクリックします。

★開いていたSSH接続ターミナルが瞬時に閉じますので停止されたことが確認できます。

タスクビューアが表示されますので完了するまでしばらく(数秒程度)待機します。

タスクビューアに「TASK OK」と表示されたらタスクの実行結果を確認します。
> shutdown(停止)とstart(起動)のタスク結果を確認し、ビューアを「X閉じ」します。

コンテナが移行先ホストに移動したことを確認します。

以上でコンテナの作成は完了です。 

 

4. HAの設定(VM・CT共通) #

 

1)HAリソース登録 #

ゲストをHAリソースに登録し、HA対象ゲストにします。

PVEではHAが常時有効となっているため、HA対象ゲストにするだけでHAは動作します。HAはホスト/ゲストどちらの状態も監視し、ホストに異常が検知されればゲストを別のホストへフェイルオーバーし、ゲストに異常が検知されればゲストを再起動します。

左メニューより「データセンター」>「HA」を選択します。
>「リソース」セクションの「追加」ボタンをクリックします。

VMのプルダウンからゲストを選択します。
注)設定項目名がVMとなっていますが、コンテナも選択可能です。

Max. Restart/Max. Relocate の上限回数を指定します。
> フェイルバックにチェックが入っていることを確認します。
> 要求状態で「started」を選択し、「追加」ボタンをクリックします。

▼設定情報
VM:登録するゲスト(VM・コンテナ)をプルダウンから選択
Max. Restart:ゲスト異常時に再起動を試行する上限回数(1~10)を指定(*1)
Max. Relocate:フェイルオーバーを試行する上限回数(1~10)を指定(*2)
フェイルバック:フェイルバックの有効/無効を指定(デフォルト:有効)(*3)
要求状態:ゲストの状態を指定(started, stopped, ignored, disabled)(*4)
  • ホスト異常時はゲストを再起動しても意味がないため、即フェイルオーバーが試行されます。再起動は1回失敗すれば2回目以降も失敗する可能性が高いため3回以下にするのが一般的です。
  • フェイルオーバーは再起動の上限を超えた時/ホスト異常時に試行されます。1ホストにつき1回しか試行されないためホスト数以上にする意味はありません。また、3台連続で失敗する可能性も低いため3回以下にするのが一般的です。
  • フェイルバックを機能させるためには、別途ノードアフィニティルールの設定が必要となります。
  • ゲストをどのような状態にしておきたいかを指定します(詳しくは以下を参考にしてください)

▼要求状態の違い

要求状態HAHAの動作利用ケース設定
時期
設定
期間
started有効起動状態を維持する(*1)本番ゲストの稼働を維持したい時事前常時
stopped停止状態を維持する(*2)待機ゲストを停止しておきたい時
ignored無効手動操作に任せる(*3)ホストやゲストをメンテしたい時臨時
disabled管理から強制排除する(*4)ロックされたゲストを解放する時事後
  • ホスト故障時に、稼働中のゲストを停止>別ホストに移動>再起動することで起動状態を維持します。
  • ホスト故障時に、停止中のゲストを別ホストに移動させますが再起動はせず停止状態を維持します。
  • システムは何もせず、手動操作に委ねます。HAリソース登録前と同様の状態でユーザーがゲストを自由に操作できるようになります。
  • フェイルオーバーが上限回数を超えて失敗すると、安全のためゲストはロックされ手動による起動もできなくなります。状態を「error」から「disabled」に変更することでロックが解除できます。

ゲストがHAリソースとして登録されたことを確認します。

 

3)アフィニティルールの設定 #

アフィニティルールとは、HA対象ゲストをどのホストに優先配置するか(ノードアフィニティ)、ゲスト同士を同居/別居させるか(リソースアフィニティ)を決めておくためのルールです。

HAに必須な設定ではないため配置に拘りがなければこの設定は必要ありませんが、故障していたホストが復旧した際にゲストをフェイルバックさせたい場合はノードアフィニティルールの設定が必須となります。

アフィニティルールに設定できるゲストはHAリソースに登録済みのゲストだけです。また、フェイルバックを利用する場合はHAリソース設定で「フェイルバック」を有効にしておく必要があります。

早速、フェイルバックを可能とする「ノードアフィニティルール」の設定を行ってゆきます。

左メニューより「データセンター」>「HA」を選択します。
> ゲストがHAリソース登録済みでフェイルバックが有効(true)になっているか確認します。
※未登録または無効(false)の場合は前項の手順を参考に登録・設定変更を行います。

左メニューより「データセンター」>「HA配下のアフィニティルール」を選択します。
>「HAノードアフィニティルール」セクションの「追加」ボタンをクリックします。

HAリソースでプルダウンから登録済みのゲストを選択します。
※複数のゲストをまとめて選択することもできます。

配置させたいホストにチェックを入れます。
> 複数のホストを選択した場合はプライオリティを付け「追加」ボタンをクリックします。

▼設定情報
HAリソース:HA対象ゲストをプルダウンから選択
ノード:配置対象ホストにチェックを入れて選択
プライオリティ:順位付けのための数値を入力(数値が大きい=優先度が高い)(*1)
Strict:有効/無効を選択(*2)
  • 数値(優先度)を同じにした場合は、システムが配置先を決めます。
  • 有効にした場合は、配置対象以外のホストへの配置が厳格に禁止されるため、配置対象ホストがいずれも利用不可だった場合、他のホストには配置されずゲストは停止してしまいます。

ルールが設定されたことを確認します。
> HA対象ゲストが最優先ホストに移動されるまでしばらく(数秒)待機します。

> HA対象ゲストが最優先ホストに自動的に移動され配置されたことを確認します。
※VMならライブマイグレーション、CTなら再起動を伴うマイグレーションとなります。

 

4)HAの動作テスト #

ホストからLANケーブルを抜いて疑似的な障害を起こし、フェイルオーバーの動作テスト行います。その後、ケーブルを挿し直して障害を復旧させ、フェイルバックの動作テスト行います。

▼テスト前の環境
・2台のゲストが存在し、どちらも同じホスト(pve03)で正常稼働している
・1台のゲスト(100)のみHAの対象とし、もう1台(150)は対象外にしている
・アフィニティルールのホスト優先度は「pve03 > pveo2 > pve01」としている

▼障害発生時に想定される正しい動作
・HA対象ゲストは、2番目に優先度が高いホストにフェイルオーバーされる
・HA対象外ゲストは、停止状態で障害ホストに留まり手動起動も不可となる

▼障害復旧時に想定される正しい動作
・HA対象ゲストは、最も優先度が高い元居たホストにフェイルバックされる
・HA対象外ゲストは、自動起動されず停止したままだが手動で起動させられる

①障害発生時のフェイルオーバーテスト

両ゲスト(100/150)が同じホスト(pve03)で稼働していることを確認します。

ホスト(pve03)に接続されているLANケーブルを抜きます。
> 10秒ほどでホストが切断状態に変わったことを確認します。
> 両ゲストともまだ稼働中であることを確認し、2分(※)待機します。
※この時間はPVEの仕様で決められている内部的に必要な待機時間です。

HA対象ゲスト(100)がホスト(pve02)に移動されたことを確認します。
> HA対象ゲスト(100)の起動が開始されたことを確認します。
> HA対象外ゲスト(150)は故障ホスト(pve03)に留まっていることを確認します。
> この時点ではHA対象外ゲスト(150)がまだ稼働中であることを確認します。

HA対象ゲスト(100)の起動が完了しフェイルオーバーが成功したことを確認します。
> HA対象外ゲスト(150)が停止されたことを確認します。
> HA対象外ゲスト(150)の手動起動ができないことを確認します。

フェイルオーバーによるダウンタイムは、OS起動時間も含め2分40秒という結果でした。

②障害復旧時のフェイルバックテスト

抜去していたLANケーブルをホスト(pve03)に挿し直します。
> 10秒ほどでホストが稼働状態に戻ったことを確認します。

HA対象ゲスト(100)が元のホスト(pve03)にフェイルバックされたことを確認します。
> HA対象外ゲスト(150)は起動されず停止されたままであることを確認します。

HA対象外ゲスト(150)が手動で起動させられるようになったことを確認します。

フェイルバックによるダウンタイムは、ライブマイグレーション可能なVMでは0秒、再起動が伴うマイグレーションが必要なコンテナでは20秒という結果でした。

以上でHAの設定は完了です。 

 

5. 複製と削除(VM・CT共通) #

 

1)クローンの作成 #

左メニューより複製したいゲストを選択します。
> 右上の「More」ボタンをクリックし、プルダウンより「クローン」を選択します。

必要に応じて設定情報を指定し、「クローン」ボタンをクリックします。

▼設定情報
ターゲットノード:稼働させたいホストを指定(デフォルト:複製元と同じ)
VM ID / CT ID:自動採番される識別番号(100以上の未使用番号なら変更も可)
名前(VMの場合):仮想マシンの識別名(未入力だとCopy-of-VM-複製元名となる)
ホスト名(CTの場合):コンテナのホスト名(未入力だと複製元と同じホスト名となる)
リソースプール:追加する場合はプルダウンから選択(後から追加も可)
ターゲットストレージ:保存先ストレージを指定(デフォルト:複製元と同じ)

複製ゲスト(新しいゲスト)が作成されたことを確認します。
> アイコンから「複製中の鍵マーク」が消えるまでしばらく待機します。

複製時間は複製元ゲストのディスク使用量(ディスク容量ではありません)によって変わってきます。当方の環境の場合、ディスク使用量1GBあたり約1分かかりました。

鍵マークが消えたら、「Start Now」または「開始」をクリックし、ゲストを起動させます。

複製ゲストが起動したことを確認します。

複製後は、IPアドレスとホスト名の変更、HAの設定が必要になります。

 

2)削除 #

左メニューよりシャットダウン済みの削除対象ゲストを選択します。
> 右上の「More」ボタンをクリックし、プルダウンより「削除」を選択します。

対象ゲストのIDを入力し、 全てのチェックボックスにチェックを入れます。
>「削除」ボタンをクリックします。

対象ゲストが削除されたことを確認します。

左メニューより「RBDストレージ」 >「VMディスク」または「CTボリューム」を選択し、ゲスト用ディスク(vm-id-disk-x)も消えていることを確認します。万が一消えていない場合は、対象ディスクを選択し削除します。

以上で複製と削除は完了です。 

 

6. バックアップとリストア(VM・CT共通) #

 

1)バックアップ #

左メニューよりバックアップしたいゲスト >「バックアップ」を選択します。
> 上部の「今すぐバックアップ」ボタンをクリックします。

設定情報を入力し、「バックアップ」をクリックします。

▼設定情報
ストレージ:プルダウンよりバックアップ先ストレージを選択(推奨:外部ストレージ)
モード:プルダウンよりモード(スナップショット/一時停止/停止)を選択
保護:バックアップを保護するか否かを選択(デフォルト:チェックなし=保護なし)
圧縮:プルダウンより圧縮方式(none/LZO/GZIP/ZSTD)を選択

タスクビューアが表示されるので完了するまでしばらく待機します。
(進行状況は%で表示されます)

タスクビューアにて「TASK OK」と表示されたらビューアを「X閉じ」します。

右上のストレージよりバックアップ先に指定したストレージを選択します。

バックアップファイルが保存されていることを確認します。

 

2)リストア #

左メニューより「バックアップ保存ストレージ 」>「バックアップ」を選択します。
> バックアップファイルを選択し、上部の「リストア」ボタンをクリックします。

必要に応じてID/名前・ホスト名/メモリ/CPUを変更し、「リストア」をクリックします。

タスクビューアにて進行状況(%)を確認

タスクビューアにて「TASK OK」と表示されたらビューアを「X閉じ」します。

リストアされたゲストが新たに作成されていることを確認します。

リストア後は、必要に応じてIPアドレスとホスト名の変更、HAの設定が必要になります。

以上でバックアップとリストアは完了です。

Updated on 2026年6月15日
HCI仮想環境の構築ProxmoxVEの導入設定
目次
  • 1. 仮想マシンとコンテナの比較
  • 2. 仮想マシン(VM)の作成
    • 1)ISOイメージのアップロード
    • 2)仮想マシン(VM)の作成
    • 3)ゲストエージェントの導入
    • 4)使用不可領域の破棄設定(Linuxのみ)
    • 5)マイグレーションのテスト
  • 3. コンテナ(CT)の作成
    • 1)テンプレートのダウンロード
    • 2)LXCコンテナの作成
    • 3)SSHサーバーの導入
    • 4)マイグレーションのテスト
  • 4. HAの設定(VM・CT共通)
    • 1)HAリソース登録
    • 3)アフィニティルールの設定
    • 4)HAの動作テスト
  • 5. 複製と削除(VM・CT共通)
    • 1)クローンの作成
    • 2)削除
  • 6. バックアップとリストア(VM・CT共通)
    • 1)バックアップ
    • 2)リストア
  • ホーム
  • ドキュメント
  • ギャラリー
  • お知らせ
  • お問い合わせ

© 2026 ktcsp.net All rights reserved.

トップへ戻る
  • ホーム
  • ドキュメント
    • 仮想基盤の構築
      • 仮想基盤について
      • HCI仮想基盤(XCP-ng+XOSTOR)
      • HCI仮想基盤(ProxmoxVE+Ceph)
    • サーバーの構築
      • 基本サーバー(Rocky Linux)
      • Mailサーバー(Postfix/Dovecot)
      • Webサーバー(Apache)
      • リバースプロキシサーバー(Nginx)
      • 内向DNSサーバー(Dnsmasq)
      • Backupサーバー(Storware)
      • 監視サーバー(Zabbix)
    • ホームページの構築
      • WordPressの導入と設定
      • ホームページの作成(Kadence)
      • ドキュメントページの作成(BetterDocs)
      • ギャラリーページの作成(NextGen Gallery)
      • 問い合わせページの作成(WPForms)
    • オンラインストレージの構築
      • Nextcloudの導入と設定
  • ギャラリー
    • ヨーロッパ
      • イタリア
      • スペイン
      • ポルトガル
      • ギリシャ
      • フランス
      • イギリス
    • アジア
      • 中国
      • 日本
    • その他
      • オーストラリア
      • ハワイ
  • お知らせ
  • お問い合わせ