vSphere 8: vCenter Server と ESXi を 7.0 から 8.0 にアップグレードする


はじめに

vSphere 8 が公開された ので、おうちラボをアップグレードしました。本エントリはその記録です。

なお、vSphere 8 から製品のリリースモデルに変更があり、従来のように いきなり GA(General Availability)ではなく、今後は IA(Initial Availability)と GA の 2 段階方式 になるようです。ということで、今回は厳密には IA リリースへのアップグレード です。

詳細は次の公式ブログのエントリで解説されていますが、ざっくりいえば、従来の GA 相当のモノをまず IA の扱いでリリース し、1 ~ 2 ヶ月ほど経って IA の採用が充分に広まったら GA 扱いに変更する ようです。GA 前の公開という意味では IA がいわゆるパブリックベータのような扱いとも思えてしまいますが、そうではなく、IA でも品質は従来の GA と何ら変わらないということのようでした。

Our intent going forward is that all major and update vSphere releases will be delivered first with an IA designation. An IA release is a production-quality release that meets all GA quality gates and is fully partner certified. IA releases will be available during the IA phase to all customers for production deployments.

We will follow up once we determine each release has achieved sufficiently wide adoption and announce the transition of the release to a GA designation. We expect this to typically happen after 4-6 weeks from IA.

New Release Model for vSphere 8 – VMware vSphere Blog

率先して新しいモノを使いたいヒト向けが IA で、ある程度ワールドワイドで実績ができてから採用したいヒト向けが GA って感じでしょうか。たぶん。

とはいえ、IA から GA まで最大で 2 ヶ月ちかく空くことになりそうなので、IA のビルドが本当に完全にそのまま GA になるのか、あるいはなんだかんだで GA にあわせてパッチリリースなど新しいビルドが出てくるのか、断定はしづらそうです。いつものビルド番号の一覧の KB(vCenter ServerESXi)では 8.0 IA と書かれているので、この行が GA に書き換わるのか、あるいは行が増えるのか、要注視ということで。

作業の流れ

今回の対象の環境は、おうちラボのうち、vSphere 7 環境を構成している第 8 世代の NUC(NUC8i5BEK)2 台です。ハードウェア面もソフトウェア面も、どちらも何も凝った構成にはしておらず、vSAN も使っていないほぼ素のままのミニマム状態です。これまで通り、次の流れで進めます。

  • vCenter Server のアップグレード
  • ESXi のアップグレード
  • 分散仮想スイッチ(vSphere Distributed Switch)のアップグレード

実際の作業内容は、当然ながら対象の構成に強く依存します。考慮事項も多数あるため、リリースノート、製品ドキュメントのアップグレードの項目、相互運用性マトリクス(Interoperability Matrices)、互換性ガイド(Compatibility Guide)あたりは確認すると安心です。いずれも次の Activity Path から追いかけられるため、これを順に進めながら確認するとよいでしょう。

個別のドキュメントは次の通りです。

vCenter Server の 7.0 から 8.0 へのアップグレード

ほぼ vCenter Server を 6.7 から 7.0 にアップグレードしたとき と同じ流れです。ステージ 1 で新しい vCSA が(仮の IP アドレスで)デプロイされ、ステージ 2 でデータの移行、IP アドレスの修正と旧 vCSA の停止が行われます。

今回も GUI インストーラを使っています。Upgrade を選択して進みます。

ステージ 1: vCenter Server のデプロイ

愚直にウィザードに従っていきます。特に難しいところはないので、抜粋しつつ画像だけ並べます。

まずは移行元の環境情報を指定します。

続く画面で移行先の環境情報を指定したら、新しい vCSA の VM 名を指定します。今回の構成では、新 vCSA が旧 vCSA と同じインベントリに並ぶことになるので、名前の競合を避けるために旧 vCSA とは別のものを指定します。

vCSA のサイズで選択できる最小サイズは、移行元の vCSA の CPU とメモリ、ディスクのサイズ(使用量ではなく割当量)から判断されるようです。今回の環境では本当は Tiny で充分ですが、元の vCSA のディスクが少し大きかったので Tiny が選べず、Small にしています。

データストアとネットワークを指定します。

構成をレビュして、問題なければデプロイを開始させます。

完了を待ちます。だいたい 10 分くらいでした。

ステージ 2: 移行元 vCenter Server のアップグレード

続けてそのままステージ 2 です。こちらも愚直にウィザードに従うのみです。

移行元の vCenter Server の情報を渡して、移行する対象のデータを選択します。過去の履歴は破棄して構わないので、今回は設定とインベントリだけ移行させます。

CEIP へ参加するといくつかの機能が有効化されるので、素直に参加します。

構成をレビュし、問題なければ移行を開始させます。

新旧 vCSA 間でデータの移行が行われ、旧 vCSA が停止されます。その後、旧 vCSA の IP アドレスなどのネットワーク設定が新 vCSA に反映されます。

完了です。データ量に大きく左右されますが、今回の環境ではだいたい 20 分くらいでした。

完成

サマリタブがタイルの並んだ新しいダッシュボードになっています。日本語表記だと少し表示崩れが気になりました(容量と使用量 のタイル)が、英語表記にしたらすっきりしました。日本語はワードラップが難しいですね。

ESXi の 7.0 から 8.0 へのアップグレード

ESXi のアップグレードには、今回は vSphere Lifecycle Manager(vLCM)の イメージ管理 を利用します。なお、vSphere 8 からは旧 VUM で使われていた ベースライン管理は非推奨 になり、次のメジャバージョンからは廃止されるようです。

vLCM を使った諸々は過去に本ブログでもいくつか取り上げていますが、vLCM やイメージ管理の概念自体が vSphere 7 からの登場だったので、メジャバージョンアップに vLCM を使うのは今回が初めてです。

とはいえ、特に難しいこともなく、ホストクラスタに対してイメージを定義して修正するだけの簡単な作業で完了します。

イメージの編集

ホストクラスタの アップデート > イメージ から適用するイメージを編集すると、ベースイメージに ESXi 8.0 が選択肢にある(表記が GA になっていますが IA の間違い……?)ので、それを選択します。

今回はハードウェアが NUC 8 なので、Community Network Devices Drivere1000-community)の最新版もアップロードして追加しました(追加方法は 以前のエントリ で紹介しています)。

ホストの修正

イメージができたら コンプライアンスの確認 をして、ホストごと、あるいはクラスタ全体で 修正 を行えば完了です。

なお、今回は使いませんでしたが、vSphere 8 から、修正作業の時間を短くするために事前にイメージを ESXi に送る ステージ と、あらかじめメンテナンスモードにしておくことで複数のホストを同時に修正する 並列修正Parallel remidiation)ができるようになっています。

完成

だいたい 10 分くらいで完了しました。

vCenter Server がある環境だとあまり触りませんが、ESXi 側の Host Client にもアップデートが入っています。

詳細はリリースノートに記載 がありますが、最新の仮想ハードウェアバージョンへの対応など順当な更新だけでなく、UI のテーマの変更のサポート、ESXi への SSH コンソール接続機能(Chrome への拡張機能のインストールが必要です)などが追加されています。

補足: vCSA の内部用 DNS サーバ化

これまで、おうちラボでは、vCSA 7.0 を内部用 DNS サーバとして使っていました。この構成を今後も維持したいので、アップグレードと同時に vCSA 8.0 に対しても同様の DNS サーバ化を行いました。

今回、ステージ 1 の完了後、ステージ 2 を開始する前に手動で構成作業を行っています。ステージ 1 までは旧 vCSA を DNS サーバとして使えますが、ステージ 2 ではその過程で旧 vCSA がシャットダウンされ名前解決ができなくなってしまうためです。ステージ 2 も最低限 /etc/hosts さえいじってあれば DNS サーバを使わずとも完遂できますが、ついでに全部やってしまっています。

ただし、ステージ 2 の最中に /etc/dnsmasq.conf がロールバックされたため、Dnsmasq の構成だけはアップグレードの完了後にも再度実行しました。

作業の内容自体は、vCSA 7.0 向けのもの とまったく一緒です。

SSH の有効化

SSH で接続して作業したいので、vCSA のコンソール(DCUI)を開いて Troubleshooting Mode Options から Enable SSH で SSH 接続を有効化します。

/etc/hosts の修正

旧 vCSA の /etc/hosts の必要なエントリを、vCSA 8.0 の /etc/hosts に移植します。

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

Dnsmasq の構成

/etc/dnsmasq.conf を修正して、Dnsmasq を再起動します。

# sed -i 's/^listen-address/#listen-address/' /etc/dnsmasq.conf
# 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-hosts
bogus-priv
log-queries
log-facility=/var/log/vmware/dnsmasq.log
domain-needed
dns-forward-max=150
cache-size=8192
neg-ttl=3600
# systemctl restart dnsmasq

ファイアウォールの構成

vCSA 用のファイアウォールの設定ファイルを作成し、設定を再読み込みさせます。

# cat << EOF > /etc/vmware/appliance/firewall/vmware-dnsmasq
{
  "firewall": {
    "enable": true,
    "rules": [
      {
        "direction": "inbound",
        "protocol": "tcp",
        "porttype": "dst",
        "port": "53",
        "portoffset": 0
      },
      {
        "direction": "inbound",
        "protocol": "udp",
        "porttype": "dst",
        "port": "53",
        "portoffset": 0
      }
    ]
  }
}
EOF
# /usr/lib/applmgmt/networking/bin/firewall-reload

動作確認

完了です。外部のホストから名前解決ができることを確認します。

$ dig kuro-esxi01.krkb.lab @192.168.0.201
...
;; ANSWER SECTION:
kuro-esxi01.krkb.lab.   0       IN      A       192.168.0.202
...

まとめ

vCenter Server と ESXi をこれまでの 7.0 から最新の 8.0 にアップグレードしました。

オンプレミスのちまっとした非 vSAN な環境だったこともあって、いつも通りな感覚であまり迷うこともなくサクサクと進められました。

とはいえ、難易度や手順は構成次第で大きく変わりますし、時代にあわせて順当に古いハードウェアや古いゲスト OS のサポートが打ち切られてもいるので、きちんとした環境で採用するときは、きちんとリリースノートやドキュメントや各種資料など一次情報に目を通しましょうということで。

@kurokobo

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

コメントを残す

メールアドレスが公開されることはありません。