oVirt 4.3 HCI環境をoVirt 4.4へアップグレード（その２）

[SRA Advent Calendar](https://qiita.com/advent-calendar/2020/sra)の5日目です。
ネットワークシステムサービス第１事業部の ふじまき です。

[oVirtアップグレード（その１）](https://qiita.com/uskf/items/81b1d863b0306f65e058)の続きです。

# 物理ホスト２号機の再構築

２台目の物理ホストをCentOS 8で再構築します。
ここでは仮に２号機としています。

## ゲスト移動
物理ホスト２号機上で稼働しているゲストがいる場合、他の物理ホストにLive Migrationさせます。
移動先は物理ホスト３号機でもよいですが、物理ホスト１号機へLive Migrationさせることもできます。

以下のゲストがoVirt 4.3と4.4の物理ホスト間で双方向にLive Migration出来ることは確認しました。

- Chipset/Firmware:クラスターのデフォルト（レガシー）<br>
  エミュレーションタイプ:クラスターのデフォルト（pc-i440fx-rhel7.6.0）<br>
  CPU:クラスターのデフォルト（Intel Skylake Client IBRS SSBD MDS Family）<br>
  OS: CentOS 7.10 / CentOS 8.2

余談ですが、EngineVMもLive Migrationさせる事が出来ます。ただし、実際にやると物理ホスト１号機が居なくなったEngineVMを復旧させようとして(?)暴れだすのでやらないように。

## 物理ホスト２号機のGlusterノードUUIDとpeer情報のバックアップ
物理ホスト１号機の時とファイル名以外同じ

```
$ ssh "物理ホスト２号機"
$ sudo tar cf - /var/lib/glusterd/glusterd.info /var/lib/glusterd/peers/ | \
  xz -9 > host2-backup.tar.xz
$ scp host2-backup.tar.xz backup.example.co.jp:~/
```

# 物理ホスト２号機の再構築
## CentOS 8インストール＠２号機
物理ホスト１号機の時同様、ホスト名、IPアドレス等は元の設定を引き継ぎます。注意事項等も同じ。
パッケージ更新、再起動

```
$ sudo dnf -y update && sudo reboot
```
langpacks-enインストール

```
$ sudo dnf -y install langpacks-en
```
## oVirt 4.4インストール＠２号機
ここも物理ホスト１号機と同じ。

oVirt 4.4のリポジトリ設定をインストール

```
$ sudo dnf -y install https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm
```
Gluster 6のリポジトリを追加

```
$ sudo dnf -y install centos-release-gluster6
```
oVirt 4.4標準のGluster 7リポジトリを無効化

```
$ sudo dnf config-manager --disable ovirt-4.4-centos-gluster7
```
oVirt HCI環境向けパッケージインストール

```
$ sudo dnf -y install cockpit-ovirt-dashboard vdsm-gluster
```

## Glusterのリストアと開始＠２号機
退避しておいたバックアップを物理ホスト２号機にコピー

```
$ scp backup.example.co.jp:~/host2-backup.tar.xz .
```

元と同じパスにリストア

```
$ xz -dc host2-backup.tar.xz | sudo tar xf - -C /
```

Brickディレクトリを準備します。新EngineVM用のボリュームが追加されているので準備するBrickディレクトリも１個増えています。

必要に応じてファイルシステム～fstab編集～マウント～Brickディレクトリを作成し、

```
$ lvcreate -L100g -n bricklv vgname
$ sudo mkfs.xfs /dev/mapper/vgname-bricklv
$ echo '/dev/mapper/vgname-bricklv /path/to/mountpoint xfs  defaults 0 0' | sudo tee -a /etc/fstab
$ sudo mount /path/to/mountpoint
$ sudo mkdir -p /path/to/mountpoint/brick
```
Brickディレクトリのowner/groupをvdsm:kvmに設定

```
$ sudo chown vdsm:kvm /path/to/mountpoint/brick
```
インデックスディレクトリ（？）作成

```
$ sudo mkdir -p /path/to/mountpoint/brick/.glusterfs/indices
```
１号機 or ３号機で全てのBrickディレクトリの拡張属性 `trusted.glusterfs.volume-id` を確認

```
# ここだけ物理ホスト１号機 or ３号機で実行
# 全てのGlusterボリュームに対して行う
$ sudo getfattr -d -m. -ehex /path/to/brick | grep trusted.glusterfs.volume-id
getfattr: Removing leading '/' from absolute path names
trusted.glusterfs.volume-id=0x41d13b6671de4a289e28b87e13a52226 # この16進数をメモ
```
確認したtrusted.glusterfs.volume-id属性を物理ホスト２号機で作成したBrickディレクトリに設定

```
# 確認した個々のGlusterボリュームのtrusted.glusterfs.volume-idを
# 物理ホスト２号機のBrickディレクトリそれぞれに設定
$ sudo setfattr -n trusted.glusterfs.volume-id \
  -v 0x41d13b6671de4a289e28b87e13a52226 /path/to/mountpoint/brick
```
Firewall設定

```
$ sudo firewall-cmd --add-service glusterfs
$ sudo firewall-cmd --add-service glusterfs --permanent
```
hostsにGlusterノードのエントリを追加

```
$ sudo vi /etc/hosts
```
サービス起動

```
$ sudo systemctl enable --now glusterd.service
$ sudo systemctl enable --now glustereventsd.service
```
物理ホスト２号機自身のBrickが起動していることを確認

```
$ sudo gluster volume status
```
ボリューム修復

```
# 全てのGlusterボリュームに対し実行
$ sudo gluster volume heal "ボリューム名" full
```
修復結果確認

```
# 全てのGlusterボリュームに対し実行
$ sudo gluster volume heal "ボリューム名" info
```

修復されない場合は物理ホスト２号機のBrick削除→追加を実施

# 物理ホスト２号機のoVirt再インストール
この時点では物理ホスト２号機はメンテナンスモードになっています。

[コンピュート]→[ホスト]で物理ホスト一覧を表示、物理ホスト２号機を選択した状態で[編集]をクリックしてホストの編集を開きます。
[全般]タブの下の方に"詳細パラメータ―"というのがあるのでクリックする物理ホストのフィンガープリントが表示されます。その下に"取得"というリンクがあるのでクリックします。
![ovirt-host-sshkey.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147346/5cdc5e1a-0acf-944f-0760-9100c143f961.png)
取得に成功すると以下のようなメッセージが表示されます。
![fingerprint-update-success.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147346/06dc8820-d131-f0e7-3e6a-78e57ed84601.png)

物理ホスト２号機のフィンガープリントを更新したらホスト一覧で物理ホスト２号機を選択した状態で[インストール]→[再インストール]を選択
![reinstall-host.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147346/e27bcc28-8aaa-cae8-d48f-dd8bf9da368d.png)

再インストールのウィザードが表示されるので、[全般]タブでrootパスワード入力
![rejoin-2nd-host-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147346/11eb5e5d-3f93-11bb-1cc6-72327baec3ca.png)
[Hosted Engine]タブで"DEPLOY"を設定
![rejoin-2nd-host-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147346/98ff3ad8-3d61-b3eb-7fad-fd91ce103325.png)
[Replace Host]タブは変更不要
![rejoin-2nd-host-3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147346/25a21193-7241-5713-0d07-14591dc9eff3.png)
[OK]をクリックすると物理ホスト２号機のインストールが開始されるので暫く待ちます。


## 物理ホスト２号機のネットワーク設定
物理ホスト１号機の時と同じなので詳細略

ここまで終わるとEngineVMも冗長性がある状態になるので一息つけます。:smiley:

# 物理ホスト３号機の再構築
物理ホスト２号機とほぼ同じなので詳細略

# Glusterのバージョンアップ
oVirt 4.3に合わせGluster 6で作ってきましたがoVirt 4.4本来はGluster 7なのでバージョンアップします。
以下を物理ホスト１台ずつ実行

Gluster7のリポジトリ有効化

```
$ sudo dnf config-manager --enable ovirt-4.4-centos-gluster7
```
Gluster 6のリポジトリ無効化

```
$ sudo dnf config-manager --disable centos-gluster6-test
```
管理画面の[コンピュート]→[ホスト]でバージョンアップ対象ホストを選択し、[インストール]→[アップグレードを確認]で更新パッケージを確認してから[インストール]→[アップグレード]

# ネットワーク設定戻し
[コンピュート]→[クラスター]でクラスタ名をクリック→[論理ネットワーク]タブ→[ネットワークを管理]をクリックしてネットワーク一覧を表示し、事前準備で外した[必須]を元に戻す
![network-required.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147346/eb9f07bf-5520-d0ae-478a-b8e66262375e.png)

# 旧EngineVM用ストレージドメイン＆Glusterボリューム削除
oVirt 4.3のEngineVMで使っていたストレージドメイン（デプロイ中に"hosted_engine_old_XXXX"にリネームされている）を削除します。

1. [ストレージ]→[ドメイン]でストレージドメイン一覧から"hosted_engine_old_XXXX"を選択しメンテナンスモードに切り替え→確認画面がでるので[OK]をクリック
1. メンテナンスモードになったら[デタッチ]→確認画面がでるので[OK]をクリック
1. [コンピュート]→[データセンター]→データセンター名をクリック→[ストレージ]タブで一覧から"hosted_engine_old_XXXX"を選択して[削除]→確認画面が出るので[OK]をクリック
1. [ストレージ]→[ボリューム]でGlusterボリューム一覧から旧Engineで使っていたGlusterボリュームを選択して[停止]→確認画面が出るので[OK]をクリック
1. 停止させたGlusterボリュームを選択して[削除]→確認画面が出るので[OK]をクリック

# oVirtのGlusterサービスの強制有効化
HCI環境なのにお前は何を言っているんだ、と言われそうですが。
クラスターの互換バージョンを上げようとしたらクラスターの編集画面でチェックが外れているのに気づきました。ダッシュボードにはGlusterボリュームの情報表示されているのに。しかもグレーアウトしていて有効にできない。
![gluster-service-disabled.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147346/08e0566a-760a-7914-f555-f632ba27ccb1.png)
（後述のCPUタイプの問題を解消した上で）この状態で互換バージョンを4.4にして[OK]をクリックすると「クラスターにボリュームが含まれているため、glusterサービスを無効にすることはできません」というエラーになります。

結論：以下手順で無理やり有効化

グローバルメンテナンスモードに切り替え

```
$ ssh "物理ホスト" # どれでもOK
$ sudo hosted-engine --set-maintenance --mode=global
```

物理ホスト上で以下のスクリプトを作成して実行（EngineVMのFQDNとadmin@internalのパスワードは適宜設定）

```python
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
 
import ovirtsdk4 as sdk
import ovirtsdk4.types as types
 
def main():
    connection = sdk.Connection(
        url='https://EngineVMのFQDN/ovirt-engine/api', # EngineVMのFQDNを設定
        username='admin@internal',
        password='redhat123', # "admin@internal"のパスワードを設定
        insecure=True,
        debug=False,
    )
 
    clusters_service = connection.system_service().clusters_service()
    cluster = clusters_service.list()[0]
    cluster_service = clusters_service.cluster_service(cluster.id)
    if cluster.gluster_service == False:
        print("oVirt Gluster service \"Disabled\"")
        cluster_config = cluster_service.get()
        cluster_config.gluster_service = True
        cluster_service.update(cluster_config)
    else:
        print("oVirt Gluster service \"Enabled\"")
 
    connection.close()
 
if __name__ == '__main__':
    main()
```
２回実行して２回目で`oVirt Gluster service "Enabled"`と表示されたら間髪入れずにEngineVMにログインしてovirt-engineサービスを再起動

```
$ ssh "EngineVM"
$ sudo systemctl restart ovirt-engine.service
```
ovirt-engine.serviceを再起動しない場合、暫くするとGlusterサービスが無効に戻ってしまう。
なお、フェンシングポリシーのGluster関連設定は有効になっていたので無効になっていたのは見た目だけの可能性あり。

グローバルメンテナンスモード解除

```
$ ssh "物理ホスト" # どれでもOK
$ sudo hosted-engine --set-maintenance --mode=none
```

# クラスター＆データセンターの互換バージョン更新
ここまでoVirt 4.3相当で動いていましたが、4.4へ上げます。

IntelのCPUを使っている場合、[名前が変更](https://www.ovirt.org/develop/release-management/features/virt/secure-cpus.html)された為、それらを使っている場合クラスターと仮想マシンのCPUタイプを変更する必要があります。

[コンピュート]→[クラスター]→一覧からクラスター名を選択して[編集]をクリック
クラスターの編集ウィンドウの[全般]タブで"CPUタイプ"を短いもの（"IBRS","SSBD","MDS"などが含まれない、"Intel Skylake Client Family"や"Intel Skylake Server Family"）に変更
![cluster-cpu-type-change.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147346/14c16820-8e84-ff23-a96e-7786d4c486b2.png)
AMD CPUは名前変更なさそうなのでこの作業は不要と思われます。

次にEngineVM以外の**全ての仮想マシン**の編集画面の[システム]タブの詳細パラメーター内の"カスタムの互換バージョン"を4.4に変更。Intel CPU環境の場合は"CPUタイプ"も一緒にクラスターに設定したものに変更（微妙に表示が省略されてますが）
![vm-version-and-cpu-type.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147346/fdabd9c9-8792-ddbb-fb1b-64c1a838a44e.png)

これで4.4へ更新できるようになったので、[コンピュート]→[クラスター]→一覧からクラスター名を選択して[編集]をクリック。
[全般]タブで互換バージョンを4.4に変更
![cluster-versionup44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147346/6647ede0-8a31-6d98-4669-2d5e51099047.png)

続けてデータセンターの互換バージョン更新
[コンピュート]→[データセンター]→データセンターを選択し[編集]をクリック
互換バージョンをプルダウンから4.4に変更
![datacenter-verup-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/147346/fea7b7b4-aa0c-38ae-5e22-0d1dce6d4a51.png)

互換バージョンが更新されるとIntel CPUの名前が新しくなるので、必要に応じて適宜直します。
なお、互換バージョン4.5はCentOS 8.3向けらしいですが、今のところ設定しようとするとエラーになります。

# 感想
４回目で成功:grinning: