古いIBM CloudのVCS環境(vSphere 6.5ベース)を順次最新化してます

# 1. はじめに

私が所属している部門では、古いIBM CloudのVCS環境(vSphere 6.5ベース)が1ノード環境で稼働しており、**ずっと利用されておらず、アクセスさえできない状態で放置**されていた。[VCSのバージョンは3.1](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vmwaresolutions-relnotes#july-2019)だったので、2019年7月頃のリリースを使っていたらしい。

- vCenter Server 6.5 Update 2g: `6.5.0.24000 build-13638625`
- EVC無効の単一クラスター
    - VMWare ESXi 6.5 Update 2: `VMware ESXi 6.5.0 build-13635690`  , `Intel Xeon-Skylake (4110-SILVER)` x 1台
- NSX for vSphere: `6.4.4 build-11197766`



vSphere6.x系もNSX for vSphere(NSX-V)もEOSが近づいており、NSX-VからNSX-Tへの移行は大掛かりになる。VCSも6.x系は2022年10月にはread-onlyになるため、新規にvSphere7/NSX-T3.xのVCS環境を作り直して、移行するのが自然である。

- [End of Support for vSphere 6.5 instance deployments](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-eos-vsphere65)
- [End of Marketing for vSphere 6.7 instance deployments](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-eos-vsphere67)
- [End of Marketing for NSX-V instance deployments](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-eos-nsx-v)

とはいうものの、NSX-VベースのVCS環境を利用しているユーザーの一助になるためとも考え、せっかくなのでこの環境を使って可能な限り延命させるというユーザーシナリオに沿って最新化を図った例を紹介したい。

# 2. そもそもパスワードも証明書も切れてアクセスできない状態を回復させる。
[vCenter6.5が証明書切れてたり管理者パスワードがわからなくなってアクセスできなかった問題への対応事例](https://qiita.com/testnin2/items/14e05a2da2d04b666941)

# 3. vCenter -> ESXi -> NSX-Vの順で現行のメジャーバージョンの中で最新化を行う

VMware社の[Product Interoperability Matrix](https://interopmatrix.vmware.com/Interoperability)に従い、アップデート中もサポートされる組み合わせを維持するため、vCenter -> ESXi -> NSX-Vの順で現行のメジャーバージョンの中で最新化を行う。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/457e4b0d-047a-242b-1c3f-fe2af423f90c.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/85133f8e-532a-cf9f-7e4d-b96a8937643c.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/98a9d6ef-4c54-2ff6-c55f-459dc675828b.png)

1. [vCenter Server 6.5 Update 3へのアップデート方法](https://qiita.com/testnin2/items/dadb8125727307121ef2)
2. [VMware ESXi 6.5 Update 3へのアップデート方法](https://qiita.com/testnin2/items/32b1c48b81db8177487f)
3. NSX for vSphereのアップデート手順を調べていると、ESXiをメンテナンスモードにした状態でNSX Managerと通信する必要がありそうだということに気が付き、1 node構成では難しいことに気が付いた。そのため、[旧VCSへの手動でのESXiノード追加方法(ESXi6.5のクラスターにESXi6.5を追加）](https://qiita.com/testnin2/items/8eef195bdc59fc64c9e6)を実施した。
4. [NSX for vSphere 6.4.13へのアップデート方法](https://qiita.com/testnin2/items/b7d24ffef3847c791b9c)

この作業により、

- vCenter Server 6.5 Update 3t: `6.5.0.40000 build-19757181`
- EVC無効の単一クラスター
    - VMWare ESXi 6.5 Update 3: `VMware ESXi 6.5.0 build-19997716`   , `Intel Xeon-Skylake (4110-SILVER)` x 2台
- NSX for vSphere: `6.4.13 build-19307994`

となった。

# 4. vCenter Server 7.0へのアップグレード

vCenter 6.5からvCenter 7.0へのアップグレードはサポートされている。
https://docs.vmware.com/jp/VMware-vSphere/7.0/com.vmware.vcenter.upgrade.doc/GUID-49E8A38B-A356-4665-8F95-38163FB3A220.html
>vSphere では、vCenter Server 6.5 以降から vCenter Server 7.0 へのアップデートをサポートします。vCenter Server 5.0、5.1、5.5 または 6.0 からアップグレードするには、まず vCenter Server インスタンスをバージョン 6.5 以降のリリースにアップグレードしてから、vCenter Server 7.0 にアップデートする必要があります。

- [vCenter 6.5からvCenter7.0へのアップグレード](https://qiita.com/testnin2/items/c619c977ad4d335b48f7)


この作業により、

- vCenter Server 7.0 Update 3f: `7.0.3.00700 Build 20051473`
- EVC無効の単一クラスター
    - VMWare ESXi 6.5 Update 3: `VMware ESXi 6.5.0 build-19997716`   , `Intel Xeon-Skylake (4110-SILVER)` x 2台
- NSX for vSphere: `6.4.13 build-19307994`

となった。


# 5. 既存クラスターにESXi7.xのノードを追加

## 5-1. 追加方法の選択肢
ESXi 7.xノードの追加方法は技術的には以下の4つの案が考えられる。

案1. 既存の単一クラスターに追加。ただし、既存の分散スイッチ(v6.5)はそのまま利用する。
案2. 既存の単一クラスターに追加。ただし、新規分散スイッチ(v7.0)を作成して、そこに追加する。
案3. 別クラスターを新規に作成してそこに追加。ただし、既存の分散スイッチ(v6.5)はそのまま利用する。
案4. 別クラスターを新規に作成してそこに追加。ただし、新規分散スイッチ(v7.0)を作成して、そこに追加する。

案2や案3は作業負担としては中途半端な延命にしかなっていないし、NSX-Tに備えて案4にするのであれば、そもそも新しいHWに新しいVCS環境でNSX-T環境を払い出す方が自動化もサポートされていて望ましいだろう。
今回は既存環境を活かしたまま、（NSX-Vのサポート切れには目を瞑って）目先の延命だけをまずは考えているので、案1の方法を選択する。
*（注意）IBM Cloudとしての推奨は、新規にvSphere7+NSX-TのVCS環境を注文し、そこにLift&Shiftでマイグレーションすることで、お客様のワークロードをHW/SW含めてサポートされる環境で動かすことです。サポートの有効期限が切れるNSX-Vを使い続けることを推奨していません。*

## 5-2. 既存の単一クラスター(ESXi6.5ベース)にESXi7を追加する際の考慮点

- 以下のようにvCenter7では同一クラスターでESXi6.5とESXi7.0を同時に管理することができる。 <br> https://docs.vmware.com/jp/VMware-vSphere/7.0/com.vmware.vcenter.upgrade.doc/GUID-49E8A38B-A356-4665-8F95-38163FB3A220.html
>vCenter Server7.0 は、ESXi 7.0 ホストのある同じクラスタ内で ESXi バージョン 6.5 ホストを管理できます。vCenter Server7.0 は ESXi 6.0 以前のホストを管理できません。 

- 既存ノードは`Intel(R) Xeon(R) Silver 4110 CPU (Skylake世代)`であり、`Cascade Lake`世代の新しい物理サーバーを追加するとクラスター内のホストによってCPU世代が変わってしまう。CPU世代が揃っていなくても、VMware HAやStorage vMotionは動く。<br> https://kb.vmware.com/s/article/1005764

>vSphere HA (High Availability): vSphere HA is not impacted due to the failover power-cycling the virtual machines when starting them on a a new host. This allows the virtual machine to pick up the new CPU ID and allows it to start without a problem
>Storage vMotion: Virtual machines are able to be moved to Storage vMotion with EVC mode disabled within a cluster

- とはいえ、Computing Resourceも自由に新旧のホスト間でvMotionできるようにしたいので、今回は既存のクラスターにEVCモードを設定した。既存サーバーのCPU世代はSkylakeではあるが、vSphere6.5の時点では、EVCとして"Broadwell" Generationまでしかサポートしていないので、今回はBroadwell Generationに設定する。
    - [旧VCSのmanagement clusterにEVCを設定する](https://qiita.com/testnin2/items/b2c927d87fc36c020957)

## 5-3. 既存の単一クラスター(ESXi6.5ベース)にESXi7を追加

- [旧VCSへの手動でのESXiノード追加方法(ESXi6.5のクラスターにESXi7.0を追加）](https://qiita.com/testnin2/items/6b67ada73c689b0d4a9f)


この作業により、

- vCenter Server 7.0 Update 3f: `7.0.3.00700 Build 20051473`
- EVC("Broadwell" Generation)を有効とした単一クラスター
    - VMWare ESXi 6.5 Update 3: `VMware ESXi 6.5.0 build-19997716` , `Intel Xeon-Skylake (4110-SILVER)` x 2台
    - VMWare ESXi 7.0 Update 3: `VMware ESXi 7.0.3 build-19898904` , `Intel Xeon-Cascade-Lake (4210)` x 1台
- NSX for vSphere: `6.4.13 build-19307994`


となった。これにより、順次ESXi6.5を削除して、ESXi7.xを追加することで、少なくともHWレベルでは当面延命できることが確認できた（NSX-Vのソフトウェア・サポートが切れてしまう問題はまた別）。


# 6. read-onlyになってしまったVCSのautomation機能を再度有効化して、既存クラスターにESXi7.を追加

これまで、ESXi6.5ベースのVCSに対して、ESXi/NSX-Vにパッチを適用し、vCenterを7.0にアップグレードして、ESXi7.0を手動でノード追加してきた。
しかし、vCenterを7.0にupgradeし、NSX-VがESXi6.xと7.xを両方サポートするNSX-V 6.4.13になっていれば、Caseを起票することで、read-onlyになっていたVCSのautomationを復活させることができるようである。ただし、追加されるノードはESXi7.xになるし、このautomationがサポートされるのもIBM CloudにおいてNSX-Vがサポートされる2023年12月31日までであるので、早めにNSX-TベースのVCSへの移行が推奨されることには変わりはなく、NSX-Vのまま利用を継続することを推奨しないのには変わりはない。

以下では、前章までの環境を

- vCenterのVM名を、（移行時に既存VMとバッティングを避けるために新規に付けたVM名ではなく）以前のVM名に戻す。
- 手動追加しない、元々の1 node環境に戻す（手動追加したESXiはインベントリーから削除し、キャンセルする）
- ただし、EVC("Broadwell" Generation)は異なるCPU世代にまたがってvMotionしたいので、有効にしたまま

という作業を追加することで、

- vCenter Server 7.0 Update 3f: `7.0.3.00700 Build 20051473`
- EVC("Broadwell" Generation)を有効とした単一クラスター
    - VMWare ESXi 6.5 Update 3: `VMware ESXi 6.5.0 build-19997716` , `Intel Xeon-Skylake (4110-SILVER)` x 1台
- NSX for vSphere: `6.4.13 build-19307994`

に一旦戻してから、VCSのautomationを再度有効にして、ESXi7環境がノード追加ができることを確認した。

- [read-onlyになってしまったVCSのautomation機能を再度有効化する](https://qiita.com/testnin2/items/58abaafbf85c8b426384)


これにより、

- vCenter Server 7.0 Update 3f: `7.0.3.00700 Build 20051473`
- EVC("Broadwell" Generation)を有効とした単一クラスター
    - VMWare ESXi 6.5 Update 3: `VMware ESXi 6.5.0 build-19997716` , `Intel Xeon-Skylake (4110-SILVER)` x 1台
    - VMware ESXi 7.0 Update 3: `VMware ESXi 7.0 Update 3e build-19898904`, `Intel Xeon-Cascade-Lake (4210)` x 1台
- NSX for vSphere: `6.4.13 build-19307994`

となった。