この記事で実現すること
前回の記事では、2台のProxmoxノード（V9.x）でクラスタを構成し、VMマイグレーションとZFSレプリケーションを使える状態にしました。
ただし、2ノードクラスタにはquorumの課題があります。片方のノードが停止した場合、残った1台だけではクラスタとしての判断が難しくなるためです。
そこで今回は、外部投票サーバーとしてqdeviceを追加し、2ノードクラスタのquorumを安定させます。さらに、HA構成を作成し、テストVMを使って障害時のフェイルオーバーを確認します。
この記事で実現すること
今回の記事では、2台のProxmoxノードでクラスタを構成します。
Proxmoxは1台構成でも十分に利用できます。しかし、ファイアウォール、認証サーバー、監視サーバーなど、自宅の基盤となるVMを動かすようになると、ホストOSのパッチ適用や再起動のたびにサービスを止めることが課題になります。
そこで今回は、2台のProxmoxノードをクラスタ化し、VMマイグレーションとZFSレプリケーションを使える状態にします。
ただし、2台構成にはquorumの課題があります。片方のノードが停止した場合や、ノード間の通信が切断された場合、残った1台だけではクラスタとして正常に判断できない場面が出てきます。
そのため、最終的にはqdeviceを追加して、2台構成の弱点を補う予定です。qdeviceは後から追加できるため、今回はまず2台クラスタを作成し、VMマイグレーションとZFSレプリケーションを使ったメンテナンス性の向上を目指します。
この記事で実現すること
仮想環境のProxmox VE9.2でCloud-Initを活用する方法をまとめています。私はこれまでは単にUbuntu Desktop VMのクローンだけで済ませており、Cloud-Initの最初の手間を考えると大して時短にもならないと考えてましたが、最近はDesktopではなくほぼUbuntu Serverに変わってきていることや小さいノードを複数持たせる傾向にあるため、改めてCloud-Initのメリットを考えてみたいと思います。
この記事で実現すること
Proxmox VE 9.2では、GUIからカスタムCPUモデルを設定できるようになりました。
これまでVMのCPUタイプは、互換性を重視する場合はx86-64-v2-AESやkvm64などを選び、性能を重視する場合はhostを選ぶ、という考え方が一般的でした。
ただし、host CPUは物理CPUの機能をVMへ大きく公開できる一方で、異なる世代のCPUを持つクラスタではライブマイグレーション時の安全性に注意が必要です。
今回、Proxmox VE 9.2のカスタムCPUモデルを使い、従来利用していたx86-64-v2-AES相当の設定と比較して、暗号処理やI/O性能にどの程度差が出るのかを検証しました。
この記事で実現すること
これまで使ってきたESXiからいよいよProxmoxに移行します。私の環境で最も大切なVMはSophos Firewallですが、移行の過程、チューニングした項目を記録に残します。
この記事で実現すること
無償版ESXi（VMware vSphere Hypervisor）について、2025-4-10にESXi8 Update3eが発表されています。今回、Broadcomサポートサイトからisoファイルをダウンロードできるようになっています。また、ESXi8 Update3dの時と同様にVMWareのサイトから製品パッチをESXi本体から直接ダウンロードし、ESXi上でパッチを適用する方法も（推奨されませんが）存在します。従来は、BroadcomからパッチのZIPファイルをダウンロードしESXiに適用する方法でしたが、ESXi8 Update3eではISOによるファイルのダウンロードおよび、（非推奨の）コマンドからのUpdateについて説明します。
この記事で実現すること
無償版ESXi（VMware vSphere Hypervisor）について、VMWareのサイトから製品パッチをESXi本体から直接ダウンロードし、ESXi上でパッチを適用します。この記事ではESXi8.0を対象にしていますが、コマンド自体はESXi7.0も変わりません。従来は、BroadcomからパッチをダウンロードしESXiに適用する方法でしたが、ESXi8 Update3dから、少し対応しづらくなってきたので別の方法を紹介します。
