Proxmox ノードのIPアドレスとノード名を変える方法

投稿者 投稿日:

余程の事情がなければProxmoxノードのIP/ノード名の変更はやめた方がいい（色々と面倒なことになりかねないため）というのは最初に言っておきたい。

それでも変更が必要になった人1のために、Claudeで作らせた手順を実際に即して一部修正を加えたものをメモしておく。

我が家の環境が2ノードでクラスタを組んでいたので、2ノードでの手順を以下に示す。

重要な注意事項

  1. ダウンタイム: この作業には数時間のダウンタイムが発生します
  2. バックアップ必須: すべてのVM/コンテナの完全なバックアップを必ず取得
  3. テスト環境: 可能であれば、テスト環境で事前に手順を確認
  4. ロールバック計画: 問題が発生した場合の元の構成への戻し方を準備
  5. コンソールアクセス: SSH接続が切れた場合に備え、物理コンソール（KVM/IPMI）を確保
  6. 作業時間: 通常業務時間外に実施
  7. 2人体制: 1人が作業、1人が確認・記録する体制が望ましい
  8. 外部バックアップ: バックアップは必ず外部ストレージにも保存

作業チェックリスト

作業の流れとしてはこんな感じになる。

  • Phase 1: バックアップ完了
    • 構成情報の保存
    • すべてのVM/コンテナのバックアップ
    • バックアップの外部保存
  • Phase 2: クラスタ解散完了
    • VM/コンテナ停止
    • ノード2削除
    • 両ノードのクラスタ設定削除
  • Phase 3: ホスト名・IP変更完了
    • ノード1変更完了
    • ノード2変更完了
    • 疎通確認OK
  • Phase 4: 新クラスタ構築完了
    • ノード1でクラスタ作成
    • ノード2がクラスタに参加
    • クラスタステータスOK
  • Phase 5: ストレージ設定完了
    • ローカルストレージ確認
    • 共有ストレージ再設定
  • Phase 6: リストア完了
    • すべてのVM/コンテナリストア
    • 起動テスト完了
  • Phase 7: 最終確認完了
    • クラスタ健全性チェックOK
    • Web UIアクセスOK
    • VM/コンテナ正常動作確認

前提条件

環境

padacha@pve0:~$ pveversion
pve-manager/8.3.2/3e76eec21c4a14a7 (running kernel: 6.8.12-5-pve)

やりたいこと

  • 192.168.10.64(pve0) -> 192.168.20.1(pve1)
  • 192.168.10.65(pve1) -> 192.168.20.2(pve2)

Phase 1: 事前準備とバックアップ

1-1. 現在の構成情報の保存

両ノードで実施:

# システム情報の保存
pvecm status > /root/cluster-status-backup.txt
pvecm nodes > /root/cluster-nodes-backup.txt
pveversion -v > /root/pve-version-backup.txt

# ネットワーク設定のバックアップ
cp /etc/network/interfaces /root/interfaces.backup
cp /etc/hosts /root/hosts.backup

# Proxmox設定全体のバックアップ
tar czf /root/pve-config-backup-$(date +%Y%m%d).tar.gz /etc/pve/

# VM/コンテナ一覧の保存
qm list > /root/vm-list-backup.txt
pct list > /root/ct-list-backup.txt

# ストレージ設定の保存
pvesm status > /root/storage-status-backup.txt
cat /etc/pve/storage.cfg > /root/storage-cfg-backup.txt

1-2. すべてのVM/コンテナのバックアップ

重要: 必ず実施してください

# 各VMのバックアップ（例: VM ID 100の場合）
vzdump 100 --mode snapshot --storage local --compress zstd

# すべてのVMを一括バックアップする場合
for vmid in $(qm list | awk '{if(NR>1)print $1}'); do
    echo "Backing up VM $vmid"
    vzdump $vmid --mode snapshot --storage local --compress zstd
done

# すべてのコンテナを一括バックアップする場合
for ctid in $(pct list | awk '{if(NR>1)print $1}'); do
    echo "Backing up CT $ctid"
    vzdump $ctid --mode snapshot --storage local --compress zstd
done

# 実行直後にログ確認
tail -20 /var/log/vzdump.log

# またはタスクの終了ステータス確認
echo $?  # 0なら成功、それ以外は失敗

Web UIでの確認:

  • ノード > Tasks タブで「Status: OK」になっているか確認
  • エラーの場合は赤字で表示されます

筆者追記：私は実行後に事後確認を行わず、クラスタを再構築してから2台目のノードでバックアップが作成されていないことに気づきました。必ず、バックアップファイルが正常に作成されているか確認しましょう。

1-3. バックアップファイルの外部保存

# バックアップの保存先確認
ls -lh /var/lib/vz/dump/

# 外部ストレージやNFSにコピー推奨
# 例: 
# rsync -avz /var/lib/vz/dump/ user@backup-server:/backups/proxmox/

Phase 2: クラスタの解散

2-1. すべてのVM/コンテナを停止

両ノードで:

# すべてのVMを停止
for vmid in $(qm list | awk '{if(NR>1)print $1}'); do
    qm stop $vmid
done

# すべてのコンテナを停止
for ctid in $(pct list | awk '{if(NR>1)print $1}'); do
    pct stop $ctid
done

# 停止確認
qm list
pct list

2-2. HAの無効化（HA使用時のみ）

# HAステータス確認
ha-manager status

# HAリソースがある場合は削除
ha-manager remove <resource>

2-3. ノード2（pve1）をクラスタから削除

ノード1（pve0）で実行:

# ノード2の削除
pvecm delnode pve1

# 確認
pvecm nodes

2-4. ノード1（pve0）のクラスタ設定削除

ノード1（pve0）で実行:

# ノード2の削除
pvecm delnode pve1

# 確認
pvecm nodes

2-5. ノード2（pve1）のクラスタ設定削除

ノード2（pve1）で実行:

# ノード2の削除
pvecm delnode pve1

# 確認
pvecm nodes

Phase 3: ホスト名とIPアドレスの変更

3-1. ノード1（pve0 → pve1, 192.168.10.64 → 192.168.20.1）

ホスト名の変更:

# 現在のホスト名確認
hostname

# 新しいホスト名の設定
hostnamectl set-hostname pve1

# 確認
hostname

ネットワーク設定の変更:

nano /etc/network/interfaces
```

以下のように設定:
```
auto lo
iface lo inet loopback

auto ens18
iface ens18 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.20.1/24
    gateway 192.168.20.254
    bridge-ports ens18
    bridge-stp off
    bridge-fd 0

hostsファイルの更新:

nano /etc/hosts
```
```
127.0.0.1 localhost.localdomain localhost
192.168.20.1 pve1.yourdomain.com pve1

# IPv6の設定があれば
::1 localhost ip6-localhost ip6-loopback

mailnameの更新（メール通知を使う場合）:

echo "pve1.yourdomain.com" > /etc/mailname

postfixの設定更新（メール通知を使う場合）:

再起動:

reboot

起動後の確認:

# ホスト名確認
hostname
cat /etc/hostname

# IPアドレス確認
ip addr show vmbr0

# ゲートウェイ確認
ip route show

# 疎通確認
ping -c 3 192.168.20.254
ping -c 3 8.8.8.8
```

### 3-2. ノード2（pve1 → pve2, 192.168.10.65 → 192.168.20.2）

**同様の手順で以下に変更:**
- ホスト名: pve2
- IPアドレス: 192.168.20.2/24
- ゲートウェイ: 192.168.20.254

**ネットワーク設定:**
```
auto lo
iface lo inet loopback

auto ens18
iface ens18 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.20.2/24
    gateway 192.168.20.254
    bridge-ports ens18
    bridge-stp off
    bridge-fd 0
```

**hostsファイル:**
```
127.0.0.1 localhost.localdomain localhost
192.168.20.2 pve2.yourdomain.com pve2

::1 localhost ip6-localhost ip6-loopback

3-2. ノード2（pve1 → pve2, 192.168.10.65 → 192.168.20.2）

同様の手順で以下に変更:

  • ホスト名: pve2
  • IPアドレス: 192.168.20.2/24
  • ゲートウェイ: 192.168.20.254

ネットワーク設定:

auto lo
iface lo inet loopback

auto ens18
iface ens18 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.20.2/24
    gateway 192.168.20.254
    bridge-ports ens18
    bridge-stp off
    bridge-fd 0

hostsファイル:

127.0.0.1 localhost.localdomain localhost
192.168.20.2 pve2.yourdomain.com pve2

::1 localhost ip6-localhost ip6-loopback

再起動後の確認も同様に実施

Phase 4: 新しいクラスタの構築

4-1. ノード1で新クラスタ作成

pve1（192.168.20.1）で実行:

# 新しいクラスタの作成
pvecm create mycluster

# 確認
pvecm status
pvecm nodes

4-2. ノード2をクラスタに参加

pve2（192.168.20.2）で実行:

# クラスタへの参加
pvecm add 192.168.20.1

# root パスワードの入力を求められます

4-3. クラスタステータスの確認

どちらのノードでも確認可能:

# クラスタステータス
pvecm status

# ノード一覧
pvecm nodes

# Corosync ステータス
corosync-cfgtool -s
corosync-quorumtool -l
```

**期待される出力:**
```
Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve1 (local)
         2          1 pve2

Phase 5: 共有ストレージの設定

5-1. ストレージ設定の確認

pve1で:

# 既存のストレージ設定確認
pvesm status

# 設定ファイル確認
cat /etc/pve/storage.cfg

5-2. 共有ストレージの再設定（必要な場合）

NFSやCIFS、Cephなどの共有ストレージを使用している場合:

# NFSの例
pvesm add nfs backup-nfs --server 192.168.20.100 --export /backup --content backup

# CIFSの例
pvesm add cifs backup-cifs --server 192.168.20.101 --share backup --username user --content backup

5-3. ローカルストレージの確認

# ローカルストレージが両ノードで認識されているか確認
pvesm status

Phase 6: VM/コンテナのリストア

6-1. バックアップファイルの確認

# バックアップファイルの一覧
ls -lh /var/lib/vz/dump/

# または Web UIで確認
# Datacenter > Backups

6-2. VM/コンテナのリストア

Web UIから:

  1. ストレージ → バックアップ を選択
  2. リストアしたいバックアップを選択
  3. “Restore” ボタンをクリック
  4. リストア先のノードとストレージを選択

コマンドラインから:

# VMのリストア（例: VM ID 100）
qmrestore /var/lib/vz/dump/vzdump-qemu-100-*.vma.zst 100

# コンテナのリストア（例: CT ID 101）
pct restore 101 /var/lib/vz/dump/vzdump-lxc-101-*.tar.zst

# 別のノードにリストアする場合は --storage オプションを使用

6-3. リストア後の確認

# VM一覧
qm list

# コンテナ一覧
pct list

# VM/コンテナの起動テスト
qm start 100
pct start 101

# 起動状態の確認
qm status 100
pct status 101

Phase 7: 最終確認とテスト

7-1. クラスタの健全性チェック

# クラスタステータス
pvecm status

# ノード間通信
ping -c 3 192.168.20.1  # pve2から実行
ping -c 3 192.168.20.2  # pve1から実行

# Corosync通信
corosync-cfgtool -s

# クォーラム確認
corosync-quorumtool -l

7-2. Web UIへのアクセス確認

両方のノードから同じクラスタ情報が見えることを確認

7-3. ストレージの確認

# ストレージステータス
pvesm status

# すべてのストレージがオンラインか確認

7-4. マイグレーションテスト（オプション）

# VMをpve1からpve2にマイグレーション（共有ストレージ使用時）
qm migrate 100 pve2

# オフラインマイグレーション（ローカルストレージの場合）
qm migrate 100 pve2 --online 0

7-5. HAの再設定（必要な場合）

# HAグループの作成
ha-manager groupadd mygroup

# リソースの追加
ha-manager add vm:100

トラブルシューティング

クォーラムが取得できない

# 期待投票数を一時的に調整
pvecm expected 1

# その後、問題を解決してから
pvecm expected 2

ノード間通信ができない

# ファイアウォール確認
iptables -L -n

# Corosync ポート確認（UDP 5404-5405）
ss -ulnp | grep corosync

# ファイアウォールを一時的に無効化してテスト
systemctl stop pve-firewall

クラスタが完全に壊れた場合

# pve1で再度クラスタ作成
systemctl stop pve-cluster corosync
rm -rf /etc/pve/corosync.conf /etc/corosync/* /var/lib/corosync/*
pmxcfs -l
systemctl start pve-cluster
pvecm create mycluster

# pve2で再参加
systemctl stop pve-cluster corosync
rm -rf /etc/pve/corosync.conf /etc/corosync/* /var/lib/corosync/*
pmxcfs -l
systemctl start pve-cluster
pvecm add 192.168.20.1

ストレージがマウントできない

# NFSの場合
showmount -e <NFS_SERVER_IP>
mount -t nfs <NFS_SERVER_IP>:/export /mnt/test

# パーミッション確認
ls -la /var/lib/vz/
```

---

## 重要な注意事項

1. **ダウンタイム**: この作業には数時間のダウンタイムが発生します
2. **バックアップ必須**: すべてのVM/コンテナの完全なバックアップを必ず取得
3. **テスト環境**: 可能であれば、テスト環境で事前に手順を確認
4. **ロールバック計画**: 問題が発生した場合の元の構成への戻し方を準備
5. **コンソールアクセス**: SSH接続が切れた場合に備え、物理コンソール（KVM/IPMI）を確保
6. **作業時間**: 通常業務時間外に実施
7. **2人体制**: 1人が作業、1人が確認・記録する体制が望ましい
8. **外部バックアップ**: バックアップは必ず外部ストレージにも保存

---

## 作業チェックリスト
```
□ Phase 1: バックアップ完了
  □ 構成情報の保存
  □ すべてのVM/コンテナのバックアップ
  □ バックアップの外部保存

□ Phase 2: クラスタ解散完了
  □ VM/コンテナ停止
  □ ノード2削除
  □ 両ノードのクラスタ設定削除

□ Phase 3: ホスト名・IP変更完了
  □ pve0 → pve1 (192.168.20.1) 変更完了
  □ pve1 → pve2 (192.168.20.2) 変更完了
  □ 疎通確認OK

□ Phase 4: 新クラスタ構築完了
  □ pve1でクラスタ作成
  □ pve2がクラスタに参加
  □ クラスタステータスOK

□ Phase 5: ストレージ設定完了
  □ ローカルストレージ確認
  □ 共有ストレージ再設定

□ Phase 6: リストア完了
  □ すべてのVM/コンテナリストア
  □ 起動テスト完了

□ Phase 7: 最終確認完了
  □ クラスタ健全性チェックOK
  □ Web UIアクセスOK
  □ VM/コンテナ正常動作確認
  1. 家族を人質に取られているとか

投稿者: padacha

自分のペースで、新たな季節を感じて。日々くだらないこと、勉強になったことを書き連ねていきます。