Proxmox VE管理ガイド

ハイパーコンバージドインフラ（HCI）は、高いインフラ需要が低い管理予算に見合う展開、リモートオフィスやブランチオフィス環境などの分散セットアップ、仮想プライベートクラウドやパブリッククラウドに特に有効です。

HCIには次のような利点があります：

Proxmox VEは、ハイパーコンバージドストレージインフラの展開を緊密に統合してサ ポートします。例えば、ウェブインタフェースのみを使用して、以下の2つのストレージテクノロジを展開および管理できます：

上記以外にも、Proxmox VEは幅広い追加ストレージテクノロジの統合をサポートしています。これらについてはストレージマネージャの章を参照してください。

主な情報源はProxmox VE Wikiです。リファレンスドキュメントとユーザー投稿コンテンツが統合されています。

Proxmox VE自体は完全なオープンソースであるため、Proxmox VEコミュニティフォーラムを利用したディスカッションや知識の共有を常にユーザーに推奨しています。このフォーラムはProxmoxのサポートチームによって管理されており、世界中から多くのユーザが参加しています。 このような大規模なフォーラムは、言うまでもなく、情報を得るのに最適な場所です。

Proxmox VEコミュニティと電子メールで迅速に連絡を取ることができます。

Proxmox VEは完全にオープンソースであり、貢献を歓迎します！開発者の主なコミュニケーションチャネルは次のとおりです：

Proxmox Server Solutions GmbHは、Proxmox VEサブスクリプションサービスプランとしてエンタープライズサポートも提供しています。 サブスクリプションを利用するすべてのユーザは、Proxmox VEエンタープライズリポジトリにアクセスでき、ベーシック、スタンダード、またはプレミアムサブスクリプションでは、Proxmoxカスタマーポータルにもアクセスできます。カスタマーポータルでは、Proxmox VE開発者による応答時間を保証したヘルプとサポートを提供します。

ボリュームディスカウント、または詳細については、sales@proxmox.com までお問い合わせください。

Proxmoxはhttps://bugzilla.proxmox.com で公開バグトラッカーを運営しています。問題が発生したら、そこに報告してください。問題はバグだけでなく、新機能や機能強化の要望でも構いません。バグトラッカーは問題を追跡するのに役立ち、問題が解決されると通知を送信します。

言語ファイルはgit リポジトリとして公開されています。git に詳しい方は、開発者向けドキュメントに従って貢献してください。

次のようにして、新しい翻訳を作成することができます（<LANG>を言語IDに置き換えてください）：

または、お好みのエディタを使用して、既存の翻訳を編集することができます：

gitに精通していなくても、Proxmox VEの翻訳を支援することができます。改善したい言語を見つけ、この言語ファイルの「raw」リンクを右クリックし、「名前を付けてリンク先を保存...」を選択してください。ファイルに変更を加え、最終的な翻訳を署名済みのコントリビューターライセンス契約書とともにoffice(at)proxmox.comに直接送ってください。

Proxmox VEで翻訳を使用するには、まず.poファイルを.jsファイルに翻訳する必要があります。これは同じリポジトリにある以下のスクリプトを実行することで可能です：

出来上がったpve-lang-xx.jsはproxmoxサーバーの/usr/share/pve-i18nディレクトリにコピーしてテストすることができます。

あるいは、リポジトリのルートから以下のコマンドを実行して、deb パッケージをビルドすることもできます：

完成した翻訳(.poファイル)は、署名済みのコントリビューターライセンス契約書とともにProxmoxチームのアドレスoffice(at)proxmox.comに送ることができます。 また、開発経験があれば、Proxmox VE開発メーリングリストにパッチとして送ることもできます。開発者向けドキュメントを参照してください。

これらの最小要件は評価のみを目的としており、本番環境では使用しないでください。

インストールされたProxmox VEシステムのCPUとハードディスクのパフォーマンスの概要を知るには、付属のpveperfツールを実行します。

ウェブベースのユーザーインターフェイスにアクセスするには、以下のブラウザのいずれかを使用することをお勧めします：

モバイルデバイスからアクセスすると、Proxmox VEは軽量でタッチベースのインターフェースを表示します。

フラッシュドライブには、少なくとも1GBのストレージが必要です。

Unix 系 OS では、ddコマンドを使って ISO イメージを USB フラッシュドライブにコピーします。まず、USBフラッシュドライブの正しいデバイス名を見つけてください（下記参照）。次にddコマンドを実行してください。

ターミナルを開きます。

hdiutilのconvertオプションなどを使って、.isoファイルを.dmg形式に変換します：

現在のデバイスのリストを取得するには、次のコマンドを実行します：

USBフラッシュ・ドライブを挿入し、このコマンドをもう一度実行して、どのデバイス・ノードが割り当てられているかを確認します。(例：/dev/diskX）。

システムのインストールと再起動が完了したら、Proxmox VEのウェブインターフェースを使用してさらに設定を行うことができます。

インストーラーは、pve というボリュームグループ（VG）と、ext4またはxfs を使用している場合はroot、data、swap という追加の論理ボリューム（LV）を作成します。これらのボリュームのサイズを制御するには

ZFS を使用する場合、インストーラは ZFS プールrpool を作成します。スワップ領域は作成されませんが、インストールディスク上にスワップ用のパーティション化されていない領域を確保することができます。インストール後に swap zvol を作成することもできますが、これは問題につながる可能性があります (ZFS swap notes を参照)。

BTRFS を使用する場合、スワップ領域は作成されませんが、スワップ用にインストー ルディスク上のパーティション化されていない領域を確保することができます。btrfs filesystem mkswapfileコマンドを使って、別パーティション、BTRFS サブボリューム、またはスワップファイルを作成できます。

ZFSは大容量のメモリで最もよく動作します。ZFSを使用する場合は、十分なRAMを用意してください。TBのRAWディスク容量に対して、4GBと1GBのRAMを追加するのが良い計算です。

ZFSは、ZFS Intent Log (ZIL)と呼ばれる専用ドライブを書き込みキャッシュとして使用できます。 これには高速ドライブ(SSD)を使用します。インストール後に以下のコマンドで追加できます：

グラフィックドライバが原因で、非常に古いハードウェアや非常に新しいハードウェアで問題が発生することがあります。ブート中にインストールがハングする場合は、nomodesetパラメータを追加してみてください。これは Linux カーネルがグラフィックドライバをロードしないようにし、BIOS/UEFI が提供するフレームバッファを使い続けるようにします。

Proxmox VE ブートローダのメニューで、[Install Proxmox VE (Terminal UI)] に移動し、eキーを押してエントリを編集します。矢印キーを使用してlinux で始まる行に移動し、カーソルをその行の最後に移動して、パラメータnomodeset を既存の最後のパラメータからスペースで区切って追加します。

次にCtrl-XまたはF10を押して設定をブートします。

リポジトリはソフトウェアパッケージの集合体であり、新しいソフトウェアをインストールするために使用できますが、新しいアップデートを取得するためにも重要です。

APTリポジトリは/etc/apt/sources.listファイルと/etc/apt/sources.list.d/に置かれた.listファイルで定義されます。

これは推奨リポジトリで、すべての Proxmox VE サブスクリプションユーザーが利用できます。pve-enterpriseリポジトリはデフォルトで有効になっています：

pve-enterpriseリポジトリにアクセスするには、有効なサブスクリプションキーが必要です。https://proxmox.com/en/proxmox-virtual-environment/pricing で詳細をご覧いただけます。

名前が示すように、このリポジトリにアクセスするためにサブスクリプションキーは必要ありません。テストや本番環境以外での使用に使用できます。本番サーバーでの使用は推奨されません。なぜなら、これらのパッケージは常に厳重にテスト・検証されているわけではないからです。

このリポジトリは/etc/apt/sources.list で設定することをお勧めします。

このリポジトリには最新のパッケージが含まれており、主に開発者が新機能をテストするために使用します。設定するには、/etc/apt/sources.list に以下の行を追加します：

このリポジトリには、エンタープライズ向けProxmox VE Ceph 19.2 Squidパッケージがあります。本番環境に適しています。Proxmox VEでCephクライアントまたは完全なCephクラスタを実行する場合は、このリポジトリを使用してください。

このCephリポジトリには、エンタープライズリポジトリに移動する前のCeph 19.2 Squidパッケージと、テストリポジトリに移動した後のCeph 19.2 Squidパッケージが格納されています。

このCephリポジトリには、メインリポジトリに移動する前のCeph 19.2 Squidパッケージが格納されています。Proxmox VEでの新しいCephリリースのテストに使用されます。

このリポジトリには、エンタープライズ向けProxmox VE Ceph 18.2 Reefパッケージがあります。本番環境に適しています。Proxmox VEでCephクライアントまたは完全なCephクラスタを実行する場合は、このリポジトリを使用します。

このCephリポジトリには、エンタープライズリポジトリに移動する前のCeph 18.2 Reefパッケージと、テストリポジトリに移動した後のCeph 18.2 Reefパッケージが格納されています。

このCephリポジトリには、メインリポジトリに移動する前のCeph 18.2 Reefパッケージが格納されています。Proxmox VEでの新しいCephリリースのテストに使用されます。

このリポジトリには、エンタープライズ向けProxmox VE Ceph Quincyパッケージがあります。本番環境に適しています。Proxmox VEでCephクライアントまたは完全なCephクラスタを実行する場合は、このリポジトリを使用します。

このCephリポジトリには、エンタープライズリポジトリに移動する前のCeph Quincyパッケージと、テストリポジトリに移動した後のCeph Quincyパッケージが格納されます。

このCephリポジトリには、メインリポジトリに移動する前のCeph Quincyパッケージが格納されています。Proxmox VEでの新しいCephリリースのテストに使用されます。

Proxmox VE 8は、Ceph Pacific、Ceph Octopus、またはハイパーコンバージドセットアップ用の古いリリースをサポートしていません。これらのリリースでは、Proxmox VE 8にアップグレードする前に、まずCephを新しいリリースにアップグレードする必要があります。

詳細については、各アップグレードガイドを参照してください。

Debian Bookworm (Proxmox VE 8) から、(DFSG で定義された) non-free ファームウェアは新しく作成された Debian リポジトリのnon-free-firmware コンポーネントに移動されました。

Early OS Microcode Updates をセットアップする場合や、プリインストールパッケージpve-firmware に含まれていないランタイムファームウェアファイルが必要な場合は、このリポジトリを有効にしてください。

このコンポーネントからパッケージをインストールできるようにするには、/etc/apt/sources.list を編集し、各.debian.orgリポジトリの行の最後にnon-free-firmwareを追加して、apt update を実行してください。

リポジトリ内のReleaseファイルは GnuPG で署名されています。APTはこれらの署名を使って、すべてのパッケージが信頼できるソースからのものであることを確認しています。

Proxmox VEを公式ISOイメージからインストールする場合、検証用のキーはすでにインストールされています。

Debianの上にProxmox VEをインストールする場合は、以下のコマンドでキーをダウンロードしてインストールしてください：

その後、sha512sumCLIツールでチェックサムを検証します：

またはmd5sumCLIツール：

このセクションは全てのデバイスに適しています。通常、BIOS/UEFI アップデートに含まれる更新されたマイクロコードはマザーボードに保存され、その他のファームウェアはそれぞれのデバイスに保存されます。この永続的な方法は、ブート時に更新されたマイクロコードをできるだけ早く定期的にロードできるようにするため、CPUにとって特に重要です。

どのアップデート方法が利用可能か、ベンダーにご確認ください。

Proxmox VE は、Proxmox 署名キーによるセキュアブートサポートを有効にするため、独自のバージョンのfwupdパッケージを同梱しています。このパッケージは、ハイパーバイザー上でのudisks2パッケージの使用に関する問題が確認されているため、 udisks2 パッケージへの依存推奨を意識的に取り除いています。つまり、/etc/fwupd/daemon.conf などで、EFI パーティションの正しいマウントポイントを明示的に設定する必要があります：

このメソッドは Proxmox VE オペレーティングシステムにファームウェアを保存し、パーシステッド ファームウェアが最新でないデバイスにファームウェアを渡します。ネットワークカードやグラフィックカードなどのデバイスでサポートされていますが、マザーボードやハードディスクなどのパーシステッドファームウェアに依存しているデバイスではサポートされていません。

Proxmox VEでは、pve-firmwareパッケージがデフォルトでインストールされています。そのため、通常のシステムアップデート(APT)で、一般的なハードウェアのファームウェアは自動的に最新の状態に保たれます。

追加のDebian ファームウェアリポジトリは存在しますが、デフォルトでは設定されていません。

追加のファームウェアパッケージをインストールしようとして競合した場合、APTはインストールを中断します。もしかしたら、そのファームウェアは別の方法で入手できるかもしれません。

マイクロコードのアップデートは、発見されたセキュリティ脆弱性やその他の深刻な CPU のバグを修正することを目的としています。CPU の性能は影響を受ける可能性がありますが、パッチを適用したマイクロコードは、通常、カーネル自身が緩和策を講じなければならないパッチを適用していないマイクロコードよりも性能が高くなります。CPU の種類によっては、故意に CPU を安全でない状態で動作させなければ、欠陥のある工場出荷状態の性能結果を達成できなくなる可能性があります。

現在のCPUの脆弱性とその緩和策の概要を知るには、lscpuを実行してください。Proxmox VEホストが最新であり、そのバージョンが終了しておらず、少なくとも最後のカーネル更新以降に再起動されている場合にのみ、現在の現実の既知の脆弱性が表示されます。

永続的なBIOS/UEFIアップデートによる推奨マイクロコードアップデート以外に、Early OS Microcode Updatesによる独立した方法もあります。これは便利で、マザーボードベンダーがBIOS/UEFIアップデートを提供しなくなった場合にも役立ちます。いずれの方法を使用する場合でも、マイクロコードアップデートを適用するには必ず再起動が必要です。

Proxmox VEは/etc/network/interfacesに直接変更を書き込みません。代わりに、/etc/network/interfaces.newという一時ファイルに書き込みます。こうすることで、関連する多くの変更を一度に行うことができます。こうすることで、関連する多くの変更を一度に行うことができます。また、間違ったネットワーク設定によってノードにアクセスできなくなる可能性があるため、適用する前に変更が正しいことを確認することができます。

現在、デバイス名には以下の命名規則を使用しています：

デバイス名がデバイス・タイプを意味するため、ネットワークの問題をデバッグしやすくなります。

現在のネットワーク構成とリソースに応じて、ブリッジ、ルーティング、マスカレードのいずれかのネットワーク設定を選択できます。

ブリッジは、ソフトウェアで実装された物理ネットワークスイッチのようなものです。 すべての仮想ゲストは単一のブリッジを共有できますが、複数のブリッジを作成してネットワークドメインを分けることもできます。各ホストは最大 4094 個のブリッジを持つことができます。

インストール・プログラムはvmbr0 という名前のブリッジを1つ作成し、最初のイーサネット・ カードに接続します。etc/network/interfacesの対応する設定は以下のようになります：

仮想マシンは、あたかも物理ネットワークに直接接続されているかのように動作します。ネットワークは、すべての仮想マシンをネットワークに接続しているネットワーク・ケーブルが1本しかないにもかかわらず、各仮想マシンを独自のMACを持っていると見なします。

ほとんどのホスティングプロバイダーは上記の設定をサポートしていません。セキュリティ上の理由から、1つのインターフェイスで複数のMACアドレスを検出するとすぐにネットワークを無効にします。

すべてのトラフィックを1つのインターフェイス経由で「ルーティング」することで、この問題を回避することができます。これにより、すべてのネットワークパケットが同じMACアドレスを使用するようになります。

一般的なシナリオは、パブリックIP（この例では198.51.100.5と仮定）と、VM用の追加IPブロック（203.0.113.16/28）がある場合です。このような場合、以下のセットアップをお勧めします：

マスカレードは、プライベートIPアドレスしか持たないゲストが、送信トラフィックにホストIPアドレスを使用してネットワークにアクセスすることを可能にします。各送信パケットはiptablesによってホストから発信されているように書き換えられ、レスポンスもそれに応じて書き換えられ、元の送信者にルーティングされます。

etc/network/interfacesに以下の行を追加すると、この問題を解決できます：

これについては、以下のリンクをご参照ください：

ネットフィルターのパケットフロー

conntrackゾーンを導入するnetdev-listのパッチ

生テーブルでTRACEを使用することで良い説明があるブログ記事

ボンディング（NICチーミングまたはリンクアグリゲーションとも呼ばれる）は、複数のNICを1つのネットワークデバイスにバインドする技術です。 ネットワークのフォールトトレラント化、パフォーマンスの向上、またはその両方など、さまざまな目的を達成することができます。

ファイバーチャネルのような高速ハードウェアと関連するスイッチングハードウェアは、かなり高価になります。リンクアグリゲーションを行うことで、2つのNICを1つの論理インターフェイスとして表示することができ、結果として2倍の速度が得られます。これはLinuxカーネルのネイティブ機能で、ほとんどのスイッチでサポートされています。ノードに複数のイーサネットポートがある場合、異なるスイッチにネットワークケーブルを接続することで、障害箇所を分散させることができます。

集約リンクは、ライブマイグレーションの遅延を改善し、Proxmox VE Clusterノード間のデータのレプリケーション速度を向上させることができます。

ボンディングには7つのモードがあります：

お使いのスイッチがLACP（IEEE 802.3ad）プロトコルをサポートしている場合は、対応するボンディングモード（802.3ad）を使用することをお勧めします。そうでない場合は、通常アクティブバックアップモードを使用してください。

クラスタネットワーク（Corosync）については、複数のネットワークで構成することをお勧めします。Corosyncはネットワークの冗長化のためのボンドを必要としません。

以下のボンド構成は、分散/共有ストレージネットワークとして使用できます。利点は、より高速になり、ネットワークがフォールトトレラントになることです。

もう1つの可能性は、ブリッジポートとしてボンドを直接使用することです。 これは、ゲストネットワークをフォールトトレラントにするために使用できます。

仮想LAN(VLAN)はブロードキャスト・ドメインで、レイヤ2のネットワーク内で分割・分離されます。 そのため、物理ネットワーク内に複数のネットワーク（4096）を持つことができ、それぞれが他のネットワークから独立しています。

各VLANネットワークは、しばしばタグと呼ばれる番号で識別されます。 ネットワークパッケージは、どの仮想ネットワークに属するかを識別するためにタグ付けされます。

Proxmox VEは、IPv6の導入の有無にかかわらず、すべての環境で正しく動作します。すべての設定はデフォルトのままにしておくことをお勧めします。

それでもノードのIPv6サポートを無効にする必要がある場合は、適切なsysctl.conf (5)スニペットファイルを作成し、適切なsysctlsを設定します。例えば、/etc/sysctl.d/disable-ipv6.confに内容を追加します：

この方法は、カーネルのコマンドラインでIPv6モジュールのロードを無効にするよりも好ましい。

デフォルトでは、仮想ゲストとそのネットワークをスムーズに使用できるように、ブリッジでMAC学習が有効になっています。

しかし、環境によってはこれが望ましくないこともあります。Proxmox VE 7.3以降では、ブリッジの'bridge-disable-mac-learning 1`設定を`/etc/network/interfaces'などで設定することで、ブリッジのMAC学習を無効にできます：

有効化されると、Proxmox VEはVMとコンテナから設定されたMACアドレスをブリッジ転送データベースに手動で追加し、ゲストが実際のMACアドレスを使用している場合のみネットワークを使用できるようにします。

場合によっては、デフォルト以外のNTPサーバを使用したいことがあります。たとえば、Proxmox VEノードが制限されたファイアウォールルールのためにパブリックインターネットにアクセスできない場合、ローカルNTPサーバをセットアップして、NTPデーモンにそれを使用するように指示する必要があります。

デフォルトのポートは2003に設定されており、デフォルトのグラファイトパスはproxmoxです。

デフォルトでは、Proxmox VEはUDPでデータを送信するため、グラファイトサーバーはこれを受け入れるように設定する必要があります。標準の1500MTUを使用しない環境では、ここで最大伝送単位(MTU)を設定することができます。

TCPを使用するようにプラグインを設定することもできます。重要なpvestatd統計収集デーモンをブロックしないために、ネットワークの問題に対処するためのタイムアウトが必要です。

Proxmox VEはUDPでデータを送信するので、influxdbサーバーはこのように設定する必要があります。必要に応じてMTUもここで設定できます。

以下は influxdb (influxdb サーバー) の設定例です：

この設定では、サーバーはポート8089ですべてのIPアドレスをリッスンし、proxmoxデータベースにデータを書き込みます。

InfluxDB 1.8.x には、この v2 API と互換性のある API エンドポイントが含まれています。

デフォルトでは、Proxmox VEはorganizationproxmoxとbucket/db proxmoxを使用します(organizationと bucketはそれぞれ設定で設定できます)。

InfluxDBのv2 APIは認証がないと使えないので、正しいバケットに書き込めるトークンを生成して設定する必要があります。

1.8.xのv2互換APIでは、トークンとしてuser:passwordを使用することができます（必要な場合）。

また、timeout設定でHTTPタイムアウト（デフォルトは1秒）を、max-body-size設定で最大バッチサイズ（デフォルトは25000000バイト）を設定できます（これは同名のInfluxDBの設定に対応します）。

このようなセットアップには、ハードウェアRAIDコントローラ（BBU付き）の使用を強くお勧めします。これにより、パフォーマンスが向上し、冗長性が確保され、ディスク交換が容易になります（ホットプラグ対応）。

LVM自体は特別なハードウェアを必要とせず、メモリ要件も非常に低くなっています。

デフォルトで2つのブートローダをインストールします。最初のパーティションには標準的な GRUB ブートローダが含まれています。2番目のパーティションはEFIシステムパーティション(ESP)で、EFIシステムでのブートと、ユーザースペースからの永続的なファームウェアアップデートの適用を可能にします。

空のディスク/dev/sdbがあり、そこに "vmdata "という名前のボリュームグループを作成するとします。

まずパーティションを作成します。

確認なしで物理 ボリューム（PV）を作成し、メタデータサイズを250Kにします。

dev/sdb1に "vmdata "というボリュームグループを作成します。

これは新しい薄いLVを作成することで簡単にできます。

実例です：

ここで、LV上にファイルシステムを作成する必要があります。

ついにこれを搭載しなければなりません。

常にアクセスできるようにするには、/etc/fstabに以下の行を追加します。

以下のコマンドでLVとメタデータプールのサイズを変更します：

シンプールは、ボリュームグループの上に作成する必要があります。 ボリュームグループの作成方法は、セクションLVMを参照してください。

ZFSはメモリに大きく依存するので、少なくとも8GBは必要です。実際には、ハードウェア/予算に見合うだけの量を使用してください。データの破損を防ぐため、高品質のECC RAMの使用をお勧めします。

専用のキャッシュおよび/またはログディスクを使用する場合は、エンタープライズクラスのSSDを使用する必要があります。これにより、全体的なパフォーマンスが大幅に向上します。

VM(入れ子仮想化)内にProxmox VEをインストールして実験している場合、VMのディスクにvirtioを使用しないでください。代わりに IDE または SCSI を使用してください (virtioSCSI コントローラタイプでも動作します)。

Proxmox VEインストーラを使用してインストールする場合、ルートファイルシステムにZFSを選択できます。インストール時にRAIDタイプを選択する必要があります：

インストーラーは自動的にディスクをパーティション分割し、rpool という ZFS プールを作成し、ZFS サブボリュームrpool/ROOT/pve-1 にルートファイルシステムをインストールします。

VM イメージを格納するために、rpool/dataという別のサブボリュームが作成されます。これをProxmox VEツールで使用するために、インストーラは/etc/pve/storage.cfgに以下の設定エントリを作成します：

インストール後、zpoolコマンドを使用してZFSプールのステータスを表示できます：

zfsコマンドは、ZFS ファイルシステムの設定と管理に使用します。次のコマンドは、インストール後のすべてのファイルシステムを一覧表示します：

ZFSプールのレイアウトを選択する際に考慮すべき要素がいくつかあります。ZFSプールの基本的な構成要素は仮想デバイス（vdev）です。プール内のすべてのvdevは等しく使用され、データはそれらの間でストライプされます(RAID0)。vdev の詳細については、zpoolconcepts(7)man ページを確認してください。

ZFS dRAID (declustered RAID)では、ホットスペアドライブがRAIDに参加します。 スペア容量は予約され、1台のドライブが故障したときの再構築に使用されます。 これにより、構成によっては、ドライブ故障時の再構築がRAIDZよりも高速になります。詳細については、OpenZFSの公式ドキュメントを参照してください。
[OpenZFS dRAIDhttps://openzfs.github.io/openzfs-docs/Basic%20Concepts/dRAID%20Howto.html] を参照してください。

その他の情報はマニュアルのページをご覧ください：

Proxmox VE はproxmox-boot-tool を使用してブートローダの設定を管理します。 詳細はProxmox VE ホスト・ブートローダの章を参照してください。

このセクションでは、一般的なタスクの使用例を紹介します。ZFS自体は本当に強力で、多くのオプションを提供しています。ZFSを管理する主なコマンドはzfsと zpoolです。どちらのコマンドにも素晴らしいマニュアルページが付属しています：

ZFSには、ZFSカーネルモジュールによって生成されたイベントを監視するイベントデーモンZEDが付属しています。新しいZFSパッケージでは、このデーモンは別のzfs-zedパッケージとして出荷されており、Proxmox VEではデフォルトでインストールされているはずです。

デーモンの設定は、/etc/zfs/zed.d/zed.rcファイルからお好みのエディタで行えます。電子メール通知に必要な設定はZED_EMAIL_ADDRで、デフォルトではrootに設定されています。

Proxmox VEはroot宛のメールをrootユーザに設定されたメールアドレスに転送しますのでご注意ください。

ZFSは、デフォルトでホストメモリの50 %を Adaptive ReplacementCache(ARC)に使用します。Proxmox VE 8.1からの新規インストールでは、ARCの使用制限はインストールされた物理メモリの10%に設定され、最大16GiBにクランプされます。この値は/etc/modprobe.d/zfs.confに書き込まれます。

ARCに十分なメモリを割り当てることは、IOパフォーマンスにとって非常に重要なので、注意して減らしてください。一般的な経験則として、少なくとも2GiB Base + 1GiB/TiB-Storageを割り当てます。たとえば、利用可能なストレージ容量が8TiBのプールがある場合、ARCには10GiBのメモリを使用する必要があります。

また、ZFSは最小値64MBを強制します。

zfs_arc_maxモジュール・パラメータに直接書き込むことで、現在のブートのARC使用制限を変更できます（再起動すると、この変更は再びリセットされます）：

ARC制限を恒久的に変更するには、/etc/modprobe.d/zfs.confに以下の行を追加します（すでにある場合は変更します）：

この設定例では、使用量を8GiB（8 *²³⁰）に制限しています。

この設定例では（一時的に）、総メモリ量が256GiBを超えるシステムでの使用量を8GiB（8 *²³⁰）に制限しています。

zvol上に作成されたスワップスペースは、サーバーをブロックしたり、外部ストレージへのバックアップを開始するときによく見られる高いIO負荷を発生させるなど、いくつかの問題を発生させる可能性があります。

メモリ不足に陥らないよう、十分なメモリを使用することを強くお勧めします。スワップを追加したい場合は、物理ディスク上にパーティションを作成し、スワップデバイ スとして使用するのが望ましいでしょう。 インストーラの詳細オプションで、この目的のために空き領域を残すことができます。さらに、"swappiness" 値を下げることもできます。サーバに適した値は 10 です：

スワップを永続的にするには、/etc/sysctl.confをお好みのエディターで開き、以下の行を追加します：

ZFS on Linux バージョン 0.8.0 では、データセットのネイティブ暗号化がサポートされました。以前の ZFS on Linux バージョンからアップグレードすると、プールごとに暗号化機能を有効にできます：

暗号化はデータセット/zvols の作成時に設定する必要があり、デフォルトで子データセットに継承されます。例えば、暗号化データセットtank/encrypted_dataを作成し、Proxmox VEのストレージとして設定するには、以下のコマンドを実行します：

このストレージ上に作成されたすべてのゲストボリューム/ディスクは、親データセットの共有鍵マテリアルで暗号化されます。

ストレージを実際に使用するには、関連するキーマテリアルをロードし、データセットをマウントする必要があります。これは

また、作成時または既存のデータセットでzfs change-keyを使用して、keylocationと keyformatプロパティを設定することで、パスフレーズのプロンプトの代わりに(ランダムな)キーファイルを使用することも可能です：

暗号化データセットの下に作成されたゲストボリュームは、それに応じてencryptionrootプロパティが設定されます。鍵マテリアルは、encryptionrootごとに1回だけロードする必要があり、その下にあるすべての暗号化データセットで使用できるようになります。

詳細と高度な使用法については、encryptionroot、encryption、keylocation、keyformat、keystatusプロパティ、zfs load-key、zfs unload-key、zfs change-keyコマンド、およびman zfsの 暗号化セクションを参照してください。

データセットで圧縮を有効にすると、ZFSは新しいブロックをすべて圧縮してから書き込み、読み込み時に解凍しようとします。既に存在するデータは遡って圧縮されません。

で圧縮を有効にできます：

lz4アルゴリズムを使用することをお勧めします。lzjbやgzip-N(Nは1(最速) から9(最高の圧縮率) までの整数) のような他のアルゴリズムも利用可能です。アルゴリズムと圧縮可能なデータによっては、圧縮を有効にすることでI/O性能が向上することもあります。

でいつでも圧縮を無効にできます：

繰り返しますが、この変更の影響を受けるのは新しいブロックだけです。

バージョン0.8.0以降、ZFSは特殊デバイスをサポートしています。プール内の特別なデバイスは、メタデータ、重複排除テーブル、およびオプションで小さなファイルブロックを格納するために使用されます。

特別なデバイスは、メタデータの変更が多い低速回転のハードディスクで構成されるプールの速度を向上させることができます。例えば、大量のファイルを作成、更新、または削除するようなワークロードでは、特別なデバイスがあると便利です。ZFSデータセットは、特別なデバイスに小さなファイル全体を保存するように設定することもでき、パフォーマンスをさらに向上させることができます。特殊デバイスには高速SSDを使用してください。

ZFSデータセットでは、special_small_blocks=<size>プロパティを公開しています。sizeには、小さなファイル・ブロックを特殊デバイスに保存しないようにする0、または512Bから 1Mの範囲の2のべき乗を指定します。このプロパティを設定すると、sizeよりも小さなファイル・ブロックが特別なデバイスに割り当てられます。

プールでspecial_small_blocksプロパティを設定すると、すべての子ZFSデータセットでそのプロパティのデフォルト値が変更されます（たとえば、プール内のすべてのコンテナは小さなファイルブロックを選択します）。

ZFSのオンディスクフォーマットへの変更は、メジャーバージョン変更の間でのみ行われ、featuresを通して指定されます。すべての機能と一般的なメカニズムは、zpool-features(5)man ページで十分に文書化されています。

新しい機能を有効にすると、古いバージョンの ZFS ではプールがインポートできなくなる可能性があるため、これは、管理者がプール上でzpool upgrade を実行して、積極的に行う必要があります (zpool-upgrade(8)man ページを参照)。

新機能を使う必要がない限り、これらを有効にしても何のメリットもありません。

実際、新しい機能を有効にすることにはデメリットもあります：

Proxmox VEインストーラを使用してインストールする場合、ルートファイルシステムにBTRFSを選択できます。インストール時にRAIDタイプを選択する必要があります：

インストーラは自動的にディスクをパーティション分割し、/var/lib/pve/local-btrfs に追加のサブボリュームを作成します。 これを Proxmox VE ツールで使用するために、インストーラは/etc/pve/storage.cfg に以下の構成エントリを作成します：

これは、デフォルトのローカル・ストレージを明示的に無効にして、追加サブボリューム上のBTRFS固有のストレージ・エントリーを優先します。

btrfsコマンドは、BTRFSファイルシステムの設定と管理に使用します。インストール後、次のコマンドで追加のサブボリュームをすべて一覧表示します：

このセクションでは、一般的なタスクの使用例を紹介します。

Wake-on-LAN (WoL) は、マジックパケットを送信することで、ネットワーク内でスリープしているコンピュータの電源を入れることができます。少なくとも1つのNICがこの機能をサポートし、コンピュータのファームウェア（BIOS/UEFI）設定でそれぞれのオプションを有効にする必要があります。オプションの名前はEnable Wake-on-LanからPower On By PCIE Device まで様々です：

pvenodeを使用すると、WoL経由でクラスタのスリープ・メンバーをスリープ解除できます：

これは、wakeonlanプロパティから取得した<node>の MAC アドレスを含む WoL magic パケットを UDP ポート 9 にブロードキャストします。ノード固有のwakeonlanプロパティは、以下のコマンドで設定できます：

WoLパケットを送信するインターフェースは、デフォルト・ルートから決定されます。以下のコマンドでbind-interfaceを設定することで上書きできます：

WoLパケットを送信する際に使用されるブロードキャストアドレス（デフォルトは255.255.255.255）は、以下のコマンドを使用してブロードキャストアドレスを明示的に設定することでさらに変更できます：

バックアップジョブの失敗など、サーバーの問題をトラブルシューティングする場合、以前に実行したタスクのログがあると役立つことがよくあります。Proxmox VEでは、pvenode taskコマンドでノードのタスク履歴にアクセスできます。

listサブコマンドを使用すると、ノードの終了したタスクのフィルタリングされたリストを取得できます。例えば、エラーで終了したVM100に関連するタスクのリストを取得するには、次のようにコマンドを実行します：

タスクのログは、そのUPIDを使って印刷できます：

多数のVM/コンテナがある場合、ゲストの起動と停止はpvenodeの startallと stopallサブコマンドで一括操作できます。 デフォルトでは、pvenode startallはブート時に自動的に起動するように設定されたVM/コンテナのみを起動します（仮想マシンの自動起動とシャットダウン参照）。両コマンドには--vmsオプションもあり、停止/起動されるゲストを指定されたVMIDに制限します。

例えば、VM100、101、102を起動するには、オンブートセットの有無に関係なく、次のようにします：

これらのゲスト（および実行中の他のゲスト）を停止するには、コマンドを使用します：

VM/コンテナがNFSサーバなどの起動の遅い外部リソースに依存している場合、Proxmox VEが起動してから、自動起動に設定されている最初のVM/コンテナが起動するまでの遅延をノードごとに設定することもできます（仮想マシンの自動起動とシャットダウンを参照）。

以下のように設定することで実現できます（ここで10は秒単位の遅延を表します）：

アップグレードの状況で、すべてのゲストをあるノードから別のノードに移行する必要がある場合、pvenodeには一括移行用のmigrateallサブコマンドも用意されています。デフォルトでは、このコマンドはシステム上のすべてのゲストをターゲットノードに移行します。しかし、ゲストのセットだけを移行するように設定することもできます。

例えば、ローカル・ディスクのライブ・マイグレーションを有効にして、VM100、101、102をノードpve2に移行するには、次のように実行します：

各Proxmox VEクラスタはデフォルトで独自の(自己署名の)認証局(CA)を作成し、前述のCAによって署名される各ノードの証明書を生成します。これらの証明書はクラスタのpveproxyサービスおよびSPICEが使用されている場合のシェル/コンソール機能との暗号化通信に使用されます。

CA証明書と鍵はProxmox Cluster File System (pmxcfs)に保存されます。

REST APIとWeb GUIは、各ノードで実行されるpveproxyサービスによって提供されます。

pveproxy が使用する証明書には、以下のオプションがあります：

オプシ ョ ン 2 と 3 では/etc/pve/local/pveproxy-ssl.pem（お よ び/etc/pve/local/pveproxy-ssl.key はパ ス ワー ド な し で） を用います。

証明書は Proxmox VE Node 管理コマンドで管理します（pvenode(1)man ページを参照）。

Proxmox VEノードに使用する証明書をすでにお持ちの場合は、Webインターフェイスから簡単にアップロードできます。

証明書の鍵ファイルが提供される場合、パスワードで保護されてはならないことに注意してください。

Proxmox VEには、自動 証明書管理 環境 ACMEプロトコルの実装が含まれており、Proxmox VEの管理者は、Let's EncryptのようなACMEプロバイダを使用して、最新のオペレーティングシステムやWebブラウザで受け入れられ、信頼されるTLS証明書を簡単にセットアップすることができます。

現在、実装されている ACME エンドポイントは、Let's Encrypt (LE) の本番環境とそのステージング環境の 2 つです。私たちのACMEクライアントは、組み込みのWebサーバーを使用したhttp-01チャレンジの検証と、acme.shが行うすべてのDNS APIエンドポイントをサポートするDNSプラグインを使用したdns-01チャレンジの検証をサポートしています。

ポート80で生成された組み込みのウェブサーバを経由してhttp-01チャレンジを検証するために、常に暗黙的に設定されたスタンドアロンプラグインがあります。

Let's Encrypts ACMEでの証明書管理に使用するには、いくつかの前提条件があります。

http-01メソッドによる検証のための外部アクセスが不可能または望ましいシステム上では、dns-01検証メソッドを使用することが可能です。 この検証メソッドは、APIを介してTXTレコードのプロビジョニングを可能にするDNSサーバーを必要とします。

ノードが ACME 提供の証明書で正しく設定されている場合（pvenode 経由または GUI 経由）、証明書はpve-daily-update.service によって自動的に更新されます。現在、証明書の有効期限が既に切れている場合、または今後30日以内に期限が切れる場合に更新が試みられます。

Proxmox VEのインストーラは、インストール用に選択されたすべてのディスクに3つのパーティションを作成します。

作成されたパーティションは

ルートファイルシステムとしてZFSを使用するシステムは、512MBのEFIシステムパーティションに保存されたカーネルとinitrdイメージで起動します。レガシー BIOS システム、およびセキュアブートが有効な EFI システムでは GRUB が使用され、セキュアブートのない EFI システムではsystemd-bootが使用されます。どちらもインストールされ、ESPを指すように設定されます。

BIOSモードのGRUB(--target i386-pc)は、GRUBで起動した全てのシステム上の選択されたディスクのBIOSブートパーティションにインストールされます
[これらは、ext4や xfs上のrootによる全てのインストールと、非EFIシステム上のZFS上のrootによるインストールです]
.

proxmox-boot-toolは EFI システムパーティションの内容を適切に設定し、同期させるためのユーティリティです。特定のカーネルバージョンを全ての ESP にコピーし、vfatフォーマットの ESP からブートするようにそれぞれのブートローダを設定します。ルートファイルシステムとしての ZFS の文脈では、これは GRUB の ZFS 実装にも存在するサブセットや、個別の小さなブートプールを作成する代わりに、ルートプールですべてのオプション機能を使用できることを意味します
[Booting ZFS on root with GRUBhttps://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS]
.

冗長性のあるセットアップでは、インストーラによってすべてのディスクがESPでパーティション設定されます。これにより、最初のブートデバイスが故障したり、BIOS が特定のディスクからしかブートできない場合でも、システムが確実に起動します。

通常の操作では、ESP はマウントされたままにはなりません。これにより、システムがクラッシュした場合にvfatフォーマットされた ESP のファイルシステムが破壊されるのを防ぎ、プライマリブートデバイスが故障した場合に/etc/fstab を手動で変更する必要がなくなります。

proxmox-boot-toolは以下のタスクを処理します：

を実行すると、現在設定されているESPとその状態を表示できます：

パーティションを同期された ESP としてフォーマットして初期化するには、例えば rpool で故障した vdev を交換した後や、同期メカニズム以前の既存のシステムを変換する場合、proxmox-kernel-helperのproxmox-boot-toolを使うことができます。

例えば、空のパーティション/dev/sda2をESPとしてフォーマットするには、以下を実行します：

dev/sda2にある既存のマウントされていないESPをProxmox VEのカーネル更新同期メカニズムに含めるように設定するには、以下を使用します：

または

を使うと、例えばセキュアブートをサポートするために、systemd-boot ではなく GRUB で初期化するように強制できます。

その後、/etc/kernel/proxmox-boot-uuidsに新しく追加されたパーティションのUUIDの行が追加されるはずです。initコマンドは、設定されているすべてのESPのリフレッシュも自動的に行います。

すべてのブータブルカーネルをコピーして設定し、/etc/kernel/proxmox-boot-uuidsにリストされているすべてのESPを同期させておくには、次のコマンドを実行するだけです：

(rootでext4またはxfsで update-grubシステムを実行するのと同じです)。

これは、カーネルコマンドラインに変更を加えたり、すべてのカーネルとinitrdsを同期させたい場合に必要です。

以下のカーネルバージョンがデフォルトで設定されています：

特定のカーネルと initrd イメージをブート可能なカーネルのリストに追加したい場合はproxmox-boot-tool kernel add を使ってください。

たとえば、以下を実行して、ABIバージョン5.0.15-1-pveのカーネルを、すべてのESPにインストールして同期しておくカーネルのリストに追加します：

proxmox-boot-tool kernel listは現在起動用に選択されている全てのカーネルバージョンを一覧表示します：

proxmox-boot-tool kernel removeを実行して、手動で選択したカーネルのリストからカーネルを削除してください：

どのブートローダが使用されているかを判断する最も簡単で確実な方法は、Proxmox VEノードのブートプロセスを見ることです。

GRUBの青いボックスか、白地に黒のシンプルなsystemd-bootが表示されます。

実行中のシステムからブートローダを判断するのは100％正確とは限りません。最も安全な方法は、以下のコマンドを実行することです：

EFI変数がサポートされていないというメッセージを返した場合、GRUBはBIOS/Legacyモードで使用されます。

出力に以下のような行がある場合、GRUBはUEFIモードで使用されています。

出力に以下のような行が含まれる場合、systemd-bootが使用されます。

走ることによって：

proxmox-boot-toolが設定されているかどうかを調べることができます。

GRUBは長年Linuxシステムをブートするためのデファクトスタンダードであり、
[GRUB Manualhttps://www.gnu.org/software/grub/manual/grub/grub.html]
。

systemd-bootは軽量な EFI ブートローダです。カーネルと initrd イメージをインストールされている EFI サービスパーティション (ESP) から直接読み込みます。 ESP から直接カーネルを読み込む主な利点は、ストレージにアクセスするためのドライバを再実装する必要がないことです。Proxmox VEではproxmox-boot-toolを使用してESP上の設定を同期させています。

カーネルコマンドラインは、使用するブートローダに応じて以下の箇所で変更できます：

カーネルコマンドラインは/etc/default/grubファイルの変数GRUB_CMDLINE_LINUX_DEFAULTに置く必要があります。update-grubを実行すると、その内容が/boot/grub/grub.cfgのすべてのlinuxエントリに追加されます。

変更を適用するには、proxmox-boot-tool refresh を実行して、loader/entries/proxmox-*.conf のすべての設定ファイルのオプション行として設定します。

カーネルパラメータの完全なリストは、https://www.kernel.org/doc/html/v<YOUR-KERNEL-VERSION>/admin-guide/kernel-parameters.html にあります。<YOUR-KERNEL-VERSION> をメジャーバージョンとマイナーバージョンに置き換えてください。例えば、バージョン 6.5 ベースのカーネルの場合、URL は次のようになります: https://www.kernel.org/doc/html/v6.5/admin-guide/kernel-parameters.html

カーネルのバージョンは、ウェブインターフェイス（Node → Summary）をチェックするか、次のコマンドを実行することで確認できます。

出力の最初の2つの数字を使用してください。

現在デフォルトでないカーネルを選択するには、以下のいずれかの方法があります：

これは、新しいカーネルバージョンとハードウェア間の非互換性を回避するのに役立つはずです。

例えばバージョン5.15.30-1-pveを恒久的に選択して起動するには、次のように実行します：

また、カーネルバージョンを次のシステムブート時にのみブートするように設定することもできます。 これは例えば、最初にバージョンを固定する原因となった問題が、更新されたカーネルによって解決されたかどうかをテストするのに便利です：

固定されているバージョン設定を削除するには、unpinサブコマンドを使用します：

unpinには --next-bootオプションもありますが、これは--next-bootで設定したpinされたバージョンをクリアするために使用します。これはブート時に自動的に行われるため、手動で実行してもほとんど意味がありません。

ピン留めされたバージョンを設定またはクリアした後は、refreshサブコマンドを実行してESPのコンテンツと設定を同期させる必要もあります。

Proxmox VE 8.1 以降、署名付きパッケージとproxmox-boot-tool の統合により、セキュアブートがすぐにサポートされます。

セキュアブートの動作には以下のパッケージが必要です。proxmox-secure-boot-support' メタパッケージを使えば一度にインストールできます。

他のブートローダは現在セキュアブートコード署名の対象になっていないため、GRUBのみがブートローダとしてサポートされています。

Proxmox VEを新規インストールすると、自動的に上記のパッケージがすべて含まれます。

セキュアブートの仕組みやセットアップのカスタマイズ方法の詳細については、wikiをご覧ください。

KSMは、仮想化環境におけるメモリ使用量を最適化することができます。これは、同様のオペレーティング・システムやワークロードを実行する複数のVMが、多くの共通メモリ・ページを共有する可能性があるためです。

しかし、KSMはメモリ使用量を削減できる一方で、VMをサイドチャネル攻撃にさらす可能性があるため、セキュリティ上のリスクも伴います。研究では、KSMの特定の特性を悪用することで、同じホスト上の2つ目のVMを介して、実行中のVMに関する情報を推測することが可能であることが示されています。

したがって、ホスティングサービスを提供するためにProxmox VEを使用している場合は、ユーザーに追加のセキュリティを提供するために、KSMを無効にすることを検討する必要があります。 さらに、KSMを無効にすることが法律で義務付けられている場合がありますので、お住まいの国の規制を確認してください。

KSMがアクティブかどうかを確認するには、以下の出力をチェックします：

もしそうなら、すぐに無効にできます：

最後に、現在マージされているすべてのページをアンマージするには、以下を実行してください：

左上にはProxmoxのロゴがあります。その隣には現在稼働中のProxmox VEのバージョンが表示されます。近くの検索バーでは、特定のオブジェクト（VM、コンテナ、ノードなど）を検索できます。これはリソースツリーでオブジェクトを選択するよりも速い場合があります。

ヘッダーの右側には4つのボタンがあります：

マイ設定］ウィンドウでは、ローカルに保存された設定を設定できます。これにはダッシュボード・ストレージが含まれ、データセンター・サマリーで表示される合計量にカウントする特定のストレージを有効または無効にできます。どのストレージにもチェックが入っていない場合は、すべてのストレージの合計になります。

ダッシュボード設定の下には、保存されたユーザー名とそれをクリアするボタン、GUI内のすべてのレイアウトをデフォルトにリセットするボタンがあります。

右側にはxterm.js Settings があります。これらには以下のオプションがあります：

これがメインのナビゲーションツリーです。ツリーの上部では、いくつかの定義済みビューを選択することができます。デフォルトのビューはサーバビューで、以下のオブジェクトタイプが表示されます：

以下のビュータイプが利用可能です：

ログパネルの主な目的は、クラスタで現在何が行われているかを表示することです。新しいVMを作成するようなアクションはバックグラウンドで実行され、このようなバックグラウンドジョブをタスクと呼びます。

このようなタスクからの出力はすべて別のログファイルに保存されます。タスクログエントリーをダブルクリックするだけで、そのログを見ることができます。そこで実行中のタスクを中止することもできます。

ここではすべてのクラスタノードから最新のタスクが表示されることに注意してください。そのため、誰かが他のクラスタノードで作業しているのをリアルタイムで確認することができます。

短時間で実行されるアクションの中には、すべてのクラスタメンバにログを送信するだけのものもあります。これらのメッセージはクラスタログパネルで見ることができます。

データセンター・レベルでは、クラスタ全体の設定と情報にアクセスできます。

クラスタ内のノードは、このレベルで個別に管理できます。

トップヘッダには、Reboot、Shutdown、Shell、Bulk Actions、Helpなどの便利なボタンがあります。Shellには、noVNC、SPICE、xterm.jsのオプションがあります。Bulk Actionsには、Bulk Start、Bulk Shutdown、Bulk Migrateのオプションがあります。

ゲストには2種類あり、どちらもテンプレートに変換することができます。 1つはカーネルベースの仮想マシン（KVM）で、もう1つはLinuxコンテナ（LXC）です。 これらのナビゲーションはほとんど同じで、一部のオプションだけが異なります。

さまざまなゲスト管理インターフェイスにアクセスするには、左側のメニューからVMまたはコンテナを選択します。

ヘッダには、電源管理、マイグレーション、コンソールへのアクセスとタイプ、クローニング、HA、ヘルプなどのコマンドを含んでいます。 これらのボタンの中にはドロップダウンメニューを含んでいるものもあります。例えば、Shutdownには他の電源オプションも含まれていますし、ConsoleにはSPICE、noVNC、xterm.js といった異なるコンソールタイプが含まれています。

右側のパネルには、左側のメニューから選択された項目のインターフェイスが含まれています。

使用可能なインターフェースは以下の通り。

ゲストインターフェイスと同様に、ストレージ用のインターフェイスは、左側にある特定のストレージ要素用のメニューと、右側にあるこれらの要素を管理するためのインターフェイスで構成されています。

このビューでは、2つのパーティションに分割されたビューがあります。 左側にはストレージオプションがあり、右側には選択したオプションの内容が表示されます。

繰り返しますが、プールビューは2つのパーティションで構成されています：左側にメニュー、右側に各メニュー項目に対応するインターフェース。

デフォルトでは、タグの色は決定論的な方法でテキストから取得されます。 色、リソースツリーでの形状、大文字と小文字の区別、およびタグのソート方法は、カスタマイズできます。こ れは、 Web イ ン タ フ ェース のDatacenter → Options → Tag Style Override で実行で き ます。または、CLI を使用して行うこともできます。たとえば

タグ例の背景色を黒 (#000000) に、文字色を白 (#FFFFFF) に設定します。

デフォルトでは、ゲスト(/vms/ID) のVM.Config.Options権限を持つユーザーは、任意のタグを設定できます (権限管理を参照)。この動作を制限したい場合は、Datacenter → Options → User Tag Access で適切な権限を設定できます：

CLIでも同じことができます。

登録タグのリストは、[Datacenter] → [Options] → [Registered Tags] で編集できます。登録されたタグのリストは、Datacenter → Options → Registered Tagsまたは CLI で編集できます。

正確なオプションとCLIでの呼び出し方法の詳細については、「データセンターの構成」を参照してください。

Datacenter → Cluster］で、［Create Cluster］をクリックします。クラスタ名を入力し、ドロップダウン・リストからメインのクラスタ・ネットワーク（リンク0）として使用するネットワーク接続を選択します。デフォルトは、ノードのホスト名で解決されたIPです。

Proxmox VE 6.2では、クラスタに最大8つのフォールバックリンクを追加できます。冗長リンクを追加するには、Addボタンをクリックし、それぞれのフィールドからリンク番号とIPアドレスを選択します。Proxmox VE 6.2以前では、フォールバックとして2つ目のリンクを追加するには、Advancedチェックボックスを選択し、追加のネットワークインターフェース（リンク1、Corosyncの冗長性も参照）を選択します。

最初のProxmox VEノードにssh経由でログインし、以下のコマンドを実行します：

新しいクラスタの状態を確認するには、次のコマンドを使用します：

同じ物理ネットワークまたは論理ネットワークに複数のクラスタを作成することができます。この場合、クラスタ通信スタックでの衝突を避けるため、各クラスタに一意の名前を付ける必要があります。さらに、クラスタを明確に区別できるようにすることで、人間の混乱を避けることができます。

corosyncクラスタの帯域幅要件は比較的低いものの、パッケージのレイテンシと1秒あたりのパッケージ（PPS）レートが制限要因となります。同じネットワーク内の異なるクラスタは、これらのリソースをめぐって互いに競合する可能性があるため、大規模なクラスタには別の物理ネットワークインフラを使用することが理にかなっている場合があります。

既存のクラスタ・ノードでWebインタフェースにログインします。Datacenter → Clusterで、上部のJoin Informationボタンをクリックします。次に、［情報をコピー］ボタンをクリックします。または、［情報］フィールドの文字列を手動でコピーします。

次に、追加するノードのWebインタフェースにログインします。Datacenter → Clusterで、Join Clusterをクリックします。情報]フィールドに、先ほどコピーした[参加情報]テキストを入力します。 クラスタへの参加に必要なほとんどの設定が自動的に入力されます。セキュリティ上の理由から、クラスタのパスワードは手動で入力する必要があります。

Joinボタンをクリックすると、クラスタ参加プロセスが直ちに開始されます。ノードがクラスタに参加すると、現在のノード証明書はクラスタ認証局(CA)から署名されたものに置き換えられます。 つまり、現在のセッションは数秒後に機能しなくなります。この場合、Webインタフェースを強制的にリロードし、クラスタ認証情報を使用して再度ログインする必要があります。

これで、Datacenter → Clusterにノードが表示されるはずです。

既存のクラスタに参加させたいノードにsshでログインします。

IP-ADDRESS-CLUSTERには、既存のクラスタ・ノードのIPまたはホスト名を使用します。 IPアドレスを使用することをお勧めします(「リンク・アドレスの種類」を参照)。

クラスタの状態を確認するには

全ノードのリストだけが必要な場合は、次のようにします：

クラスタ・ネットワークが分離されているクラスタにノードを追加する場合は、link0パラメータを使用してそのネットワーク上のノードのアドレスを設定する必要があります：

クロノスネットのトランスポート・レイヤーに内蔵されている冗長性を使用したい場合は、link1パラメータも使用してください。

GUIを使用して、Cluster Joinダイアログの対応するLink Xフィールドから正しいインターフェイスを選択できます。

ノードを最初から再インストールせずに、クラスタからノードを分離することもできます。ただし、クラスタからノードを削除した後も、そのノードは共有ストレージにアクセスできます。これは、クラスタからノードの削除を開始する前に解決しておく必要があります。Proxmox VEクラスタは他のクラスタとまったく同じストレージを共有することはできません。さらに、VMIDの競合につながる可能性もあります。

分離したいノードだけがアクセスできる新しいストレージを作成することをお勧めします。例えば、NFS上の新しいエクスポートや新しいCephプールなどです。まったく同じストレージが複数のクラスタからアクセスされないようにすることが重要です。このストレージを設定したら、すべてのデータとVMをノードからそのストレージに移動します。これで、クラスタからノードを分離する準備が整いました。

まず、ノードのcorosyncとpve-clusterサービスを停止します：

クラスタファイルシステムをローカルモードで再度起動します：

corosync設定ファイルを削除します：

これで、ファイルシステムを通常のサービスとして再開できます：

これでノードはクラスタから切り離されました。クラスタの残りのノードから削除するには

残りのノードのクォーラムが失われたためにコマンドが失敗した場合、回避策として予想得票数を1に設定することができます：

そしてpvecm delnodeコマンドを繰り返します。

次に、分離したノードに戻り、そのノードに残っているクラスタファイルをすべて削除します。これにより、ノードを問題なく別のクラスタに追加できるようになります。

他のノードの設定ファイルがまだクラスタ ファイル システムに残っているため、それらもクリーンアップします。ノード名が正しいことを確認したら、/etc/pve/nodes/NODENAMEからディレクトリ全体を再帰的に削除します。

Proxmox VEクラスタスタックを安定して動作させるには、全ノード間のレイテンシが5ミリ秒（LANパフォーマンス）以下の信頼性の高いネットワークが必要です。ノード数が少ないセットアップでは、より高いレイテンシのネットワークでも動作する可能性がありますが、これは保証されておらず、ノード数が3つ以上、レイテンシが約10ミリ秒を超えると、むしろ可能性が低くなります。

corosyncはあまり帯域幅を使用しませんが、レイテンシのジッターの影響を受けやすいので、ネットワークは他のメンバーによって多用されるべきではありません。 特に、corosyncとストレージに共有ネットワークを使わないでください（冗長構成で優先順位の低いフォールバックの可能性を除いて）。

クラスタをセットアップする前に、ネットワークがその目的に適しているかどうかを確認することは良い習慣です。クラスタ・ネットワーク上でノードが互いに接続できることを確認するには、pingツールでノード間の接続性をテストします。

Proxmox VEファイアウォールが有効な場合、corosyncのACCEPTルールが自動的に生成されます。

パラメータなしでクラスタを作成する場合、corosyncクラスタのネットワークは通常、WebインタフェースおよびVMのネットワークと共有されます。セットアップによっては、ストレージトラフィックも同じネットワーク上で送信されるかもしれません。corosyncはタイムクリティカルでリアルタイムなアプリケーションなので、これを変更することをお勧めします。

corosyncリンクアドレス（後方互換性のため、corosync.confでは ringX_addrと表記）は、2つの方法で指定できます：

ホスト名を優先する場合は、corosync専用の別個の静的ホスト名を推奨します。また、クラスタ内のすべてのノードがすべてのホスト名を正しく解決できることを確認してください。

Proxmox VE 5.1以降、サポートされている間は、ホスト名は入力時に解決されます。解決されたIPのみが設定に保存されます。

以前のバージョンでクラスタに参加したノードは、corosync.confで未解決のホスト名をまだ使用している可能性があります。上記のように、IPまたは別のホスト名で置き換えるのが良いかもしれません。

実行中のコンフィギュレーションに新しいリンクを追加するには、まずcorosync.confファイルの編集方法を確認してください。

次に、nodelistセクションのすべてのノードに新しいringX_addr を追加します。Xはどのノードに追加しても同じで、各ノードで一意であることを確認してください。

最後に、Xを上記で選択したリンク番号に置き換えて、下図のような新しいインターフェイスを トーテムセクションに追加します。

1番のリンクを追加したと仮定すると、新しい設定ファイルは次のようになります：

最後の手順でcorosync.confファイルを編集すると、すぐに新しいリンクが有効になります。再起動は必要ありません。corosyncが新しいリンクを読み込んだかどうかは、次のようにして確認できます：

1つのノードで古いリンクを一時的に切断し、切断中もステータスがオンラインであることを確認して、新しいリンクをテストするのがよいでしょう：

健全なクラスタ状態が表示された場合は、新しいリンクが使用されていることを意味します。

Proxmox VEシステムでは、SSH設定/セットアップに以下の変更が行われます：

カスタム.bashrc や、設定されたシェルによってログイン時に実行される同様のファイル がある場合、ssh はセッションが正常に確立されると、自動的にそれを実行します。これは予期せぬ動作を引き起こす可能性があります。 なぜなら、これらのコマンドは上記のどの操作に対しても root 権限で実行される可能性があるからです。これは問題となる副作用を引き起こす可能性があります！

このようなややこしいことを避けるためには、/root/.bashrcに、セッションが対話型であることを確認するチェックを追加し、その上で.bashrcコマンドを実行することをお勧めします。

このスニペットを.bashrcファイルの先頭に追加してください：

Corosync Quorum Device (QDevice)は、各クラスタノード上で動作するデーモンです。外部で実行されるサードパーティのアービトレーターの決定に基づいて、クラスタのクォーラムサブシステムに設定された投票数を提供します。 このデバイスの主な用途は、標準のクォーラムルールが許容するよりも多くのノード障害をクラスタが維持できるようにすることです。外部デバイスはすべてのノードを見ることができるため、これは安全に行うことができます。 これは、サードパーティの投票を受け取った後、そのノードのセットがクォーラムを（再び）持つことができる場合にのみ行われます。

現在、QDevice Netのみがサードパーティ・アービトレーターとしてサポートされています。これは、ネットワーク経由でパーティションメンバーに到達できる場合、クラスタのパーティションに投票を提供するデーモンです。複数のクラスタをサポートするように設計されており、設定やステートはほとんど不要です。新しいクラスタは動的に処理され、QDeviceを実行しているホスト上に設定ファイルは必要ありません。

外部ホストの唯一の要件は、クラスタへのネットワークアクセスが必要であることと、corosync-qnetdパッケージが利用可能であることです。私たちはDebianベースのホスト用のパッケージを提供していますが、他のLinuxディストリビューションでもそれぞれのパッケージマネージャから利用可能なパッケージがあるはずです。

偶数ノード数のクラスタではQDeviceをサポートし、2ノードクラスタではより高い可用性を提供する場合に推奨しています。 奇数ノード数のクラスタでは、現在のところQDeviceの使用を推奨していません。その理由は、クラスタタイプごとにQDeviceが提供する投票数に差があるためです。偶数のクラスタには追加の票が1票入りますが、これは可用性を高めるだけで、QDevice自体に障害が発生した場合は、QDeviceをまったく使用しない場合と同じ状態になるからです。

一方、クラスタサイズが奇数の場合、QDeviceは(N-1)票を提供します。この代替動作は理にかなっています。もしQDeviceに1票しか追加の票がなかったら、クラスタが分裂してしまう可能性があります。このアルゴリズムでは、1つのノード（当然QDevice自体も）を除くすべてのノードが失敗することができます。しかし、これには2つの欠点があります：

欠点とその意味を理解すれば、奇数クラスタのセットアップでこの技術を使うかどうかを自分で決めることができます。

corosync-qdeviceへの投票を提供するデーモンは、非特権ユーザーとして実行することをお勧めします。Proxmox VEとDebianにはそのように設定されたパッケージが用意されています。 Proxmox VEにQDeviceを安全かつセキュアに統合するには、デーモンとクラスタ間のトラフィックを暗号化する必要があります。

まず、外部サーバーにcorosync-qnetdパッケージをインストールします。

とcorosync-qdeviceパッケージを全クラスタノードにインストールします。

これを実行した後、クラスタ内のすべてのノードがオンラインであることを確認します。

Proxmox VEノードの1つで以下のコマンドを実行して、QDeviceをセットアップできます：

クラスタのSSHキーが自動的にQDeviceにコピーされます。

すべてのステップが正常に完了すると、「完了」と表示されます。でQDeviceがセットアップされたことを確認できます：

corosync.confファイルの編集は必ずしも簡単ではありません。各クラスタ・ノードに2つあり、1つは/etc/pve/corosync.confに、もう1つは/etc/corosync/corosync.confにあります。クラスタ・ファイル・システムにあるものを編集すると、ローカルのものに変更が伝搬しますが、その逆はできません。

ファイルが変更されるとすぐに、設定は自動的に更新されます。 つまり、実行中のcorosyncに統合できる変更は、即座に反映されます。従って、編集中にファイルを保存する際に意図しない変更を引き起こさないように、常にコピーを作成し、代わりにそれを編集する必要があります。

次に、すべてのProxmox VEノードにプリインストールされているnanoやvim.tinyなどのお気に入りのエディタで設定ファイルを開きます。

必要な変更を行った後、現在の作業用設定ファイルのコピーをもう1つ作成します。これは、新しい設定の適用に失敗したり、その他の問題が発生した場合のバックアップとして機能します。

そして、古い設定ファイルを新しいものに置き換えます：

変更が自動的に適用されるかどうかは、以下のコマンドで確認できます：

変更が自動的に適用されない場合は、corosyncサービスを再起動する必要があります：

エラーについては、以下のトラブルシューティングのセクションを確認してください。

移行タイプは、移行データを暗号化された(安全な) チャネルで送信するか、暗号化されていない(安全でない) チャネルで送信するかを定義します。 移行タイプを安全でないに設定すると、仮想ゲストの RAM コンテンツも暗号化されずに転送されることになり、ゲスト内部の重要なデータ (パスワードや暗号化キーなど) の情報漏えいにつながる可能性があります。

従って、ネットワークを完全に制御できず、誰にも盗聴されていないことを保証できない場合は、安全なチャネルを使用することを強くお勧めします。

暗号化には多くの計算パワーが必要なため、この設定はパフォーマンスを向上させるためにしばしば安全でない設定に変更されます。最近のシステムはハードウェアでAES暗号化を実装しているため、その影響は小さくなっています。パフォーマンスへの影響は、10Gbps以上の転送が可能な高速ネットワークで特に顕著です。

デフォルトでは、Proxmox VEはクラスタ通信が行われるネットワークを使用して移行トラフィックを送信します。これは、機密性の高いクラスタトラフィックが中断される可能性があることと、このネットワークがノードで利用可能な最良の帯域幅を持たない可能性があるため、いずれも最適ではありません。

移行ネットワークパラメータを設定すると、すべての移行トラフィックに専用ネットワークを使用できます。メモリに加えて、これはオフライン移行のストレージトラフィックにも影響します。

移行ネットワークはCIDR表記を使用したネットワークとして設定されます。これには、各ノードに個別のIPアドレスを設定する必要がないという利点があります。Proxmox VEは、CIDR形式で指定されたネットワークから移行先ノードの実アドレスを判断できます。これを有効にするには、各ノードがそれぞれのネットワークで正確に1つのIPを持つようにネットワークを指定する必要があります。

クラスタ・ファイル・システム内の特定のディレクトリは、ノード独自の設定ファイルを指すためにシンボリックリンクを使用します。したがって、以下の表で指すファイルはクラスタの各ノードで異なるファイルを指します。

で冗長なsyslogメッセージを有効にできます：

で、冗長なsyslogメッセージを無効にします：

推奨される方法は、クラスタからノードを削除した後にノードを再インストールすることです。これにより、すべての秘密クラスタ/sshキーと共有設定データが確実に破棄されます。

場合によっては、再インストールせずにノードをローカルモードに戻したいこともあります。

nodes/<NAME>/qemu-server/(VM)およびnodes/<NAME>/lxc/(コンテナ)内のゲスト設定ファイルについて、Proxmox VEはそれぞれのゲストの所有者として含まれるノード<NAME>を認識します。このコンセプトにより、ゲスト設定の同時変更を防止するために、高価なクラスタ全体のロックの代わりにローカルロックを使用できます。

その結果、ゲストの所有ノードに障害が発生した場合(たとえば、停電、フェンシングイベントなど)、(オフラインの)所有ノードのローカルロックが取得できないため、(すべてのディスクが共有ストレージにある場合でも)通常のマイグレーションはできません。Proxmox VEの高可用性スタックには、フェンスで保護されたノードからのゲストの正しい自動回復を保証するために必要な（クラスタ全体の）ロックとウォッチドッグ機能が含まれているため、これはHA管理されたゲストの問題ではありません。

HA管理されていないゲストが共有ディスクのみを持つ場合 (そして、障害ノードでのみ利用可能な他のローカルリソースがない場合)、/etc/pve/内の障害ノードのディレクトリからオンラインノードのディレクトリにゲスト設定ファイルを移動するだけで、手動での復旧が可能です (これにより、ゲストの論理的な所有者または場所が変更されます)。

たとえば、ID100のVMをオフラインのノード1から別のノードnode2にリカバリするには、クラスタの任意のメンバーノードでrootとして次のコマンドを実行します：

多くのストレージと QEMU イメージフォーマットqcow2 はシンプロビジョニングをサポートしています。 シンプロビジョニングを有効にすると、ゲストシステムが実際に使用するブロックのみがストレージに書き込まれます。

例えば、32GBのハードディスクでVMを作成し、ゲストシステムOSをインストールした後、VMのルートファイルシステムに3GBのデータが含まれているとします。 この場合、ゲストVMが32GBのハードディスクを見ていたとしても、ストレージには3GBしか書き込まれません。このように、シンプロビジョニングでは、現在利用可能なストレージブロックよりも大きなディスクイメージを作成することができます。VMのために大きなディスクイメージを作成し、必要性が生じたときに、VMのファイルシステムのサイズを変更することなく、ストレージにディスクを追加することができます。

スナップショット」機能を持つすべてのストレージタイプは、シンプロビジョニングもサポートしています。

各ストレージプールは<type>を持ち、<STORAGE_ID>で一意に識別されます。プール構成は次のようになります：

<type>: <STORAGE_ID>行がプール定義を開始し、その後にプロパティのリストが続きます。ほとんどのプロパティは値を必要とします。いくつかのプロパティは、妥当なデフォルトを持ち、その場合、値を省略することができます。

具体的には、インストール後のデフォルトのストレージ構成を見てください。local という名前の特別なローカルストレージプールが 1 つ含まれており、これは/var/lib/vzディレクトリを参照し、常に使用可能です。Proxmox VEのインストーラは、インストール時に選択したストレージタイプに応じて、追加のストレージエントリを作成します。

いくつかのストレージ特性は、異なるストレージタイプ間で共通です。

イメージ・タイプのボリュームには所有関係が存在します。このようなボリュームは、それぞれVMまたはコンテナによって所有されます。例えば、ボリュームlocal:230/example-image.rawは VM 230 が所有します。ほとんどのストレージバックエンドは、この所有者情報をボリューム名にエンコードします。

VMまたはコンテナを削除すると、そのVMまたはコンテナが所有する関連ボリュームもすべて削除されます。

ストレージプールの追加

ストレージプールの無効化

ストレージプールの有効化

ストレージオプションの変更/設定

ストレージプールを削除します。これはいかなるデータも削除しませんし、何かを切断したりアンマウントしたりもしません。ストレージ構成を削除するだけです。

ボリュームの割り当て

ローカル・ストレージに4Gボリュームを割り当てます。<name>に空の文字列を渡すと、名前が自動生成されます。

全巻無料

保管状況一覧

収納内容一覧

VMIDで割り当てられたボリュームの一覧

リストisoイメージ

コンテナテンプレートの一覧

ボリュームのファイルシステムのパスを表示

ボリュームlocal:103/vm-103-disk-0.qcow2をファイルターゲットにエクスポートします。 これは主にpvesmインポートで内部的に使用されます。 ストリーム形式qcow2+sizeはqcow2形式とは異なるため、エクスポートしたファイルをVMにアタッチすることはできません。 これは他の形式でも同様です。

このバックエンドは、一般的なストレージ・プロパティをすべてサポートしており、さらに 2 つのプロパティを追加しています。pathプロパティはディレクトリを指定するために使用します。これはファイルシステムの絶対パスである必要があります。

オプションのcontent-dirsプロパティで、デフォルトのレイアウトを変更できます。このプロパティは、コンマで区切られた識別子のリストで構成されます：

vtypeはストレージに許可されているコンテンツ・タイプの1つで、pathはストレージのマウントポイントからの相対パスです。

上記の構成では、backup というストレージ・プールを定義しています。このプールは、VMごとに最大7つの通常バックアップ(keep-last=7)と3つの保護バックアップを保存するために使用できます。バックアップ・ファイルの実際のパスは、/mnt/backup/custom/backup/dir/... です。

このバックエンドは、VMイメージに対して明確に定義された命名スキームを使用します：

VM テンプレートを作成すると、すべての VM イメージの名前が変更され、読み取り専用になり、クローンのベースイメージとして使用できるようになります：

上述したように、ほとんどのファイルシステムはスナップショットをサポートしていません。この問題を回避するために、このバックエンドはqcow2内部のスナップショット機能を使うことができます。

クローンも同様です。バックエンドはqcow2のベースイメージ機能を使ってクローンを作成します。

以下のコマンドを使用して、ローカル・ストレージに4GBのイメージを割り当ててください：

実際のファイルシステムのパスは

で画像を削除できます：

バックエンドは、常に設定される共有フラグを除く、すべての一般的なストレージ・プロパティをサポートしています。さらに、以下のプロパティがNFSサーバの設定に使用されます：

NFSマウントオプションも設定できます：

NFSはスナップショットをサポートしていませんが、バックエンドはqcow2の機能を使ってスナップショットとクローンを実装しています。

でエクスポートされたNFS共有のリストを取得できます：

バックエンドは、常に設定される共有フラグを除く、すべての一般的なストレージプロパティをサポートしています。さらに、以下の CIFS 特別プロパティが使用可能です：

CIFSはストレージレベルでのスナップショットをサポートしていません。しかし、スナップショットやクローン機能を使用したい場合は、qcow2バッキングファイルを使用することができます。

でエクスポートされたCIFS共有のリストを取得できます：

そして、この共有をProxmox VEクラスタ全体のストレージとして追加します：

ストレージ・プール・タイプ:pbs

このバックエンドを使用すると、Proxmox Backup Serverを他のストレージと同様にProxmox VEに直接統合できます。 Proxmox Backupストレージは、Proxmox VE API、CLI、またはWebインターフェイスから直接追加できます。

ストレージプールのタイプ:glusterfs

GlusterFSはスケーラブルなネットワークファイルシステムです。モジュラーデザインを採用し、コモディティハードウェア上で動作し、低コストで可用性の高いエンタープライズストレージを提供します。このシステムは数ペタバイトまで拡張可能で、数千のクライアントを扱うことができます。

ストレージプールのタイプ：zfspool

このバックエンドを使うと、ローカルのZFSプール（またはプール内のZFSファイルシステム）にアクセスできます。

ストレージ・プールのタイプ:lvm

LVMは、ハードディスクとパーティションの上にある軽いソフトウェアレイヤーです。利用可能なディスクスペースをより小さな論理ボリュームに分割するために使用できます。LVMはLinuxで広く使用されており、ハードドライブの管理を容易にします。

もう1つの使用例は、大きなiSCSI LUNの上にLVMを置くことです。そうすれば、iSCSI LUN上のスペースを簡単に管理することができます。iSCSI仕様ではスペース割り当て用の管理インターフェイスが定義されていないため、他の方法では不可能です。

ストレージ・プールのタイプ:lvmthin

LVMは通常、ボリュームの作成時にブロックを割り当てます。LVMのシンプールは、代わりに、書き込み時にブロックを割り当てます。ボリュームは物理的に利用可能なスペースよりもはるかに大きくなる可能性があるため、この動作はシン・プロビジョニングと呼ばれます。

通常のLVMコマンドラインツールを使用して、LVMシンプールを管理および作成できます(詳細については、man lvmthinを参照してください)。pveというLVMボリュームグループが既にあると仮定すると、以下のコマンドは、dataという新しいLVMシンプール(サイズ100G)を作成します：