vCenter Server を 6.7 から 7.0 にアップグレードする

はじめに
vSphere 7.0 の理解と準備
vCenter Server のアップグレードプロセス
vCenter Server のアップグレード
アップグレード後の確認と後処理
vCenter Server の最新パッチ適用
- トラブル：アップデートが進まない
- 解決策： VAMI を使わない
まとめ
補足： vCSA 自身を vCSA 用の DNS サーバにする
追記

はじめに

最近 vSphere 7 が出たので、おうちの牧場をアップグレードします。

この牧場は、物理的には Intel の NUC（NUC8i5BEK）にインストールした vSphere 6.7 が 2 台で、その片方に vCSA 6.7 が居る状態です。共有ストレージとして QNAP（iSCSI/NFS）がありますが、諸々の事情で vCSA は ESXi のローカルデータストア（M.2 SSD）に配置しています。外部認証ソースも外部 PSC も使っていない、ミニマムな感じです。

サポートされるアップグレード順序は、KB78221 で説明されています。今回の環境はとてもちまっとしたアレなので、素直に vCenter Server を上げてから ESXi を上げるのみです。

Update sequence for vSphere 7.0 and its compatible VMware products (78221)

このエントリでは、vCenter Server のアップグレードだけを扱います。

ESXi のアップグレードもこの後でもちろんしますが、これには VUM の後継である vSphere Lifecycle Manager（vLCM）を使ってみたいので、別エントリとして投稿しています。

vSphere 7.0 の理解と準備

根本的に、vSphere 7.0 になって、

ESXi 6.0 以前のサポートが廃止された（6.5 以上が必須）
Windows 版の vCenter Server が廃止された
外部 PSC が廃止された（アップグレードの過程で統合される）
Flash ベースの vSphere Web Client が廃止された

などなど、アーキテクチャレベルでいろいろ変更があります。

そういう何やかやふくめ、アップグレードにあたっては何はともあれドキュメント読みましょうねという感じなので、KB や製品ドキュメントを一通り見ておきます。

ここからリンクされている KB や関連ドキュメントもざっくり眺めます。マジメなことをいうとそもそも vSphere 7.0 はぼくが使っている NUC への導入をサポートしていませんが、7.0 に限らず昔からそう（アップグレード前の状態でそもそも非サポートな状態）なので気にしないことにします。

OEM のドライバを使っている場合はどうしろとか、現行バージョンが vCSA の 6.7 U2c か U3 なら事前にコレをやれとか、いろいろ書いてあるので、該当する場合はその通りにするとして、凝ったことををしていない今回のようなシンプルな構成であれば、実際の作業はウィザードをぽちぽちするレベルで終わりです。

もちろん、現行が外部データベースを使っていたり、めちゃくちゃ古かったり、外部 PSC が居たり、そもそも Windows 版だったり、外部 VUM を立てていたりすると、いろいろ考慮事項も当然でてくるので、その辺りはドキュメントを読んでください。

vCenter Server のアップグレードプロセス

標準のアップグレード手順に従う場合、処理の流れはだいたいこんな感じです。一連の作業は、ウィザードに従うと自動で順次行われます。

新しい vCSA インスタンスがデプロイされます。この段階では、IP アドレスは作業用の一時的なもの（作業時に指定）が付与されます
現行の vCSA から、構成情報がエクスポートされます
新しい vCSA にエクスポートされたデータを転送します
現行の vCSA が停止され、現行の vCSA が使っていた IP アドレスや FQDN が新しい vCSA に設定されます
エクスポートされたデータを使って、新しい vCSA に構成が復元されます

この後、状態を確認して、必要な後処理（これもドキュメントがありますが、典型的にはライセンスの投入など）を行えば、vCenter Server のアップグレードは完了です。

新しい vCSA を現行の vCSA と同じインベントリに配置する場合、作業の流れの都合上、仮想マシン名は現行の vCSA のものとは別にする必要があります。この場合、もし仮想マシン名も現行のものを維持したいのであれば、あとから手作業で仮想マシン名の変更（と、ファイル名まで気にする場合は Storage vMotion）が必要です。

vCenter Server のアップグレード

やっていきます。今回は Windows の端末上で GUI インストーラを使って作業しました。

ISO をマウントして、./vcsa-ui-installer/win32/installer.exe を叩くとインストーラが立ち上がるので、[Upgrade] を選択します。

あとは愚直にウィザードに従っていきます。まずは Stage 1 です。

現行の vCSA の情報を入力して、接続を確認します。認証情報と、現行の vCSA それ自体が動作している ESXi の情報も入力します。

新しい vCSA のデプロイ先の ESXi の情報を入力します。

新しい vCSA の仮想マシン名とパスワードを指定します。新しい vCSA が現行の vCSA と同じインベントリに並ぶことになる場合は、現行の vCSA と同じ仮想マシン名だとこの段階で怒られるので、別の名前を入れます。

新しい vCSA のサイズを指定します。

新しい vCSA を配置するデータストアを指定します。シンプロビジョニングにしたい場合はチェックも入れます。

新しい vCSA が利用するポートグループを選択して、バージョンアップ中だけ利用される一時 IP アドレスなどを入力します。

確認画面で [FINISH] を押下すると、デプロイが始まります。

デプロイ先に指定した ESXi を見ると、新しい仮想マシンができて、パワーオンされる様子が観察できます。vCSA 7.0 は、Photon OS 3.0 がベースのようですね、vCSA 6.7 は Photon OS 1.0 でした。

で、終わると、Stage 2 への進め方が案内されます。[CONTINUE] を押下するか、指示された URL にアクセスして続行します。

ここから Stage 2 です。[NEXT] で進むと、アップグレードの事前チェックが開始されます。

このアップグレードの事前チェックでエラーがあると先に進めないので、その場合はどうにかして直します。

今回は、環境固有の構成（6.7 の構築時点で手抜きして DNS サーバを立てずに強引にごまかしていた）の都合上、名前解決関連でエラーになったので、この段階で新しい vCSA に SSH でログインしてごにょごにょして修正しました。この方法は本筋ではないので本エントリの末尾で補足します。

エラーを解消したあとも警告がいくつか残りましたが、エラーでなく警告であれば、確認の上で続行できます。今回は想定内の警告のみだったので、そのまま進めました。

アップグレードするデータの種類を選びます。構成情報だけでなく、過去のタスクやイベント、パフォーマンスの統計情報なども移行できるようですが、その分データ量や作業時間は増えるようです。今回は、せっかくなので全部にしました。

CEIP を構成します。参加すると、表示されている機能が使えるようになります。逆にいえば、参加しないとこれらの機能は使えなくなります。参加状態は後からも変更できます。

現行 vCSA のバックアップを取得済みであることを宣言して続行します。バックアップ、実は取っていませんでしたが、失敗してもまあヨシな環境なのでそのまま進めました。

最後の最後に、現行 vCSA が停止する旨の確認がでて、了承すると実際の処理が開始します。

あとは待ちです。移行のデータは新旧の vCSA 間で直接やりとりされます。作業端末は経由しません。

移行データのエクスポートがひと通り終わると、現行 vCSA がシャットダウンされ、新しい vCSA の構成やサービスの起動、移行データの適用が始まります。この段階から、新しい vCSA が旧 vCSA の IP アドレスなどを持つようになります。

完了しました。

アップグレード後の確認と後処理

完了後、vSphere Client の URL にアクセスすると、確かに HTML5 版のみになっていました。

見た目や操作感は vSphere 6.x の頃とほとんど変わりません。

移行作業中に指定した通り、設定やインベントリ情報だけでなく、過去のタスクやイベント、パフォーマンスの統計情報などもきれいに残っています。

ただ、すぐに目に入るだけでも、

vCenter Server のライセンスが評価モードに変わっている
旧 vCSA の仮想マシンが残っている
新 vCSA の仮想マシン名は作業中に指定したもののままだ

あたりは対処が必要そうです。

ライセンスキーは 6.x と 7.x で違うので再適用が必要なのは当然ですが、仮想マシン名は、実体のファイル名まで気にする場合は Storage vMotion でデータストアを移行しないといけないので、ちょっと注意ですね。

vCenter Server の最新パッチ適用

アップグレードが終わったので、アップデートをしようとしました。

vSphere Client からは、Update Planner を利用して、アップデート（パッチ）の有無や適用の事前チェック結果などを確認できます。ただし、この Update Planner は、CEIP に参加していないと使えない（エラーが出る）ようです…… 謎仕様ですね。

既定では、vCSA に接続された ISO ファイルの中身と VMware の公開リポジトリがアップデートの取得先として探索されます。定期的なアップデートの自動チェックも設定できます。

トラブル：アップデートが進まない

で、実際の適用は、VAMI から数クリックで行える…… はずなので、VAMI にログインして、最新のアップデートをいちどステージングして、その後インストールを開始したところ、

プログレスバーが『インストールが進行中です』で 0 % からまったく進まない
別セッションで VAMI にログインしようとすると『アップデートの進行中です』が表示されてログインできない
パフォーマンスチャートを見ても何も動いていなさそう

な状態になってしまいました。予想ダウンタイムが 254 分というのもにわかには信じがたい数字です。

解決策： VAMI を使わない

調べるとどうも KB があります。

Accessing the VAMI returns error “Update installation in progress” after recovering from a failed update (67179)

内部でいちどコケていたのか何なのか、進捗がうまく更新されなかったみたいですね。素直に KB の通りにやってみます。

# cat /etc/applmgmt/appliance/software_update_state.conf
{
    "state": "INSTALL_IN_PROGRESS",
    "version": "7.0.0.10400",
    "latest_query_time": "2020-07-18T16:04:05Z",
    "operation_id": "/storage/core/software-update/install_operation"
}

# cp /etc/applmgmt/appliance/software_update_state.conf /tmp/software_update_state.conf.org

# service-control --stop applmgmt
Operation not cancellable. Please wait for it to finish...
Performing stop operation on service applmgmt...
Successfully stopped service applmgmt

# rm /etc/applmgmt/appliance/software_update_state.conf

# service-control --start applmgmt
Operation not cancellable. Please wait for it to finish...
Performing start operation on service applmgmt...
Successfully started service applmgmt

# cat /etc/applmgmt/appliance/software_update_state.conf
{
    "state": "UP_TO_DATE"
}

これで、たしかにログインできるようになりました。GUI で見る限りではインストール前の状態に戻っています。

が、ふたたび GUI からインストールをしようとしたら、再発しました……。

仕方ないので、再度復旧させて、今度は CLI でアップデートを試してみます。見てみると、そもそもステージングが正しくされていない模様。

Command> software-packages list --staged
 [2020-07-19T02:07:58.201] : Packages not staged

GUI の表示がおかしそうなので、GUI からはいちどステージングを解除して、

ステージング自体も今度は CLI から行います。

Command> software-packages stage --url --acceptEulas
 [2020-07-19T02:10:46.201] : Not running on a VMC Gateway appliance.
 ...
 [2020-07-19T02:10:47.201] : Staging process completed successfully

Command> software-packages list --staged
 [2020-07-19T02:11:16.201] :
        category: Bugfix
        ...
        version: 7.0.0.10400
        updateversion: True
        allowedSourceVersions: [7.0.0.0,]
        buildnumber: 16386292
        ...

目的のモノがステージングされてくれたので、インストールします。

Command> software-packages install --staged
 [2020-07-19T02:14:52.201] : Validating software update payload
 [2020-07-19 02:14:52,670] : Running validate script.....
 [2020-07-19T02:14:53.201] : Validation successful
 [2020-07-19 02:14:53,680] : Copying software packages 127/127
 [2020-07-19 02:17:10,915] : Running system-prepare script.....
 [2020-07-19 02:17:12,928] : Running test transaction ....
 [2020-07-19 02:17:14,945] : Running prepatch script.....
 [2020-07-19 02:18:42,103] : Upgrading software packages ....
 [2020-07-19T02:20:09.201] : Setting appliance version to 7.0.0.10400 build 16386292
 [2020-07-19 02:20:09,265] : Running patch script.....
 [2020-07-19 02:26:47,947] : Starting all services ....
 [2020-07-19T02:26:48.201] : Services started.
 [2020-07-19T02:26:48.201] : Installation process completed successfully

10 分くらいで終わりました。254 分とは……？

無事に最新になっています。

Command> com.vmware.appliance.version1.system.version.get
Version:
   Version: 7.0.0.10400
   Product: VMware vCenter Server Appliance
   Build: 16386292
   Type: vCenter Server with an embedded Platform Services Controller
   Summary: Patch for VMware vCenter Server 7.0.0
   Releasedate: June 23, 2020
   Installtime: 2020-07-18T22:37:32.988Z

そんなわけで、もしかすると vCSA のアップデートは VAMI より CLI のほうがトラブルを招きにくいかもしれませんね。そのうち修正されるだろうとは思いますが……。

まとめ

vSphere 6.7 環境のうち、vCenter Server を 7.0 にアップグレードし、パッチの適用も行いました。

アップグレードプロセスや全体的な使用感も 6.7 とは大きく変わっていないので、これまで通り安心して使えそうです。サクサク動いてくれて快適です。

次のエントリでは、vLCM を利用した ESXi のアップグレードとパッチ管理を行っていきます。

補足： vCSA 自身を vCSA 用の DNS サーバにする

アップグレード前、つまり 6.7 の構築時点で手抜きをしていたので、今回の環境内には DNS サーバがありません。このため、アップグレードの Stage 2 の冒頭の事前チェックで、新しい vCSA から現行の vCSA のホスト名が解決できずにエラーになりました。

アップグレード前の vCSA 6.7 は、DNS サーバがなくても FQDN で構成できるようにするため、vCSA 自身を vCSA 用の DNS サーバにしていました。具体的には、

vCSA の /etc/hosts にエントリを追加する
vCSA で動作している Dnsmasq に /etc/hosts を参照させる

ことをしていました。なお、自宅のラボなので好きにやっていましたが、もちろん非サポートです。

同じことは vCSA 7.0 でも有効なようですし、DNS サーバをわざわざ立てるのもアレなので、今回もこれを行いました。もちろん非サポートです。

Stage 1 のあと、かつ Stage 2 の前であれば、すでに vCSA への SSH ができる状態なので、指定していた一時 IP アドレスに接続して、/etc/hosts に必要なエントリを追記します。

# vi /etc/hosts
# cat /etc/hosts
...
192.168.0.201 kuro-vcs01.krkb.lab kuro-vcs01
192.168.0.200 kuro-qnap01.krkb.lab kuro-qnap01
192.168.0.202 kuro-esxi01.krkb.lab kuro-esxi01
192.168.0.203 kuro-esxi02.krkb.lab kuro-esxi02

この後、Dnsmasq の設定ファイルを修正して、Dnsmasq が /etc/hosts のエントリを DNS クエリへの応答に利用できるようにします。no-hosts をコメントアウトして、オマケで bogus-priv を足すだけです。

# sed -i 's/^no-hosts/#no-hosts\nbogus-priv/' /etc/dnsmasq.conf
# cat /etc/dnsmasq.conf
listen-address=127.0.0.1
bind-interfaces
user=dnsmasq
group=dnsmasq

no-negcache
#no-hosts
bogus-priv
log-queries
log-facility=/var/log/vmware/dnsmasq.log
domain-needed
dns-forward-max=150
cache-size=8192
neg-ttl=3600

この後、Dnsmasq を再起動します。

# systemctl restart dnsmasq

これで、OS がホスト名の名前解決を試みたときに、透過的に /etc/hosts のエントリも応答されるようになりました。dig や nslookup で確認できます。

# dig kuro-esxi01
...
;; ANSWER SECTION:
kuro-esxi01.            0       IN      A       192.168.0.202

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
...

vCSA（というか Photon OS）は、名前解決時の第一参照先が（/etc/resolv.conf で） 127.0.0.1:53 になっています。vCSA の場合は、このポートで Dnsmasq が待ち受けているため、上記の手順で名前解決に透過的に /etc/hosts が利用できたということです。

なお、DNS サーバがなくても、すべて FQDN でなく IP アドレスを指定してデプロイすれば、上記のような面倒なことをしなくても構築は可能です。

追記

後日、上記の 7.0.0.10400（7.0.0b）からさらに新しい 7.0.0.10600（7.0.0c）にアップデートした際は、GUI からの操作ですんなり完了できました。

@kurokobo

くろいです。ギターアンサンブルやら音響やらがフィールドの IT やさんなアルトギター弾き。たまこう 48 期ぎたさん、SFC '07 おんぞう、新日本ギターアンサンブル、Rubinetto。今は野良気味。