なんだか偉そうなことを書いていますが、これは自分への戒めでしょう。
さて、コロナ渦ということもあり、クラウド化がより一層強くなってきた昨今ではありますが、
一部の殿様企業様はオンプレミスに拘るところもありますね…
（外に情報を持ち出せない。っていう理由もありますけど）
まだスラリンはクラウドの世界の仕事少なそうです。
という訳で今回もvSphere関連の備忘録。
複数のESXiホストを管理するvCenterというものがあります。（雑な認識）
こいつ、インストール時や使用時に名前解決ができないと色々問題を起こします。
というか、インストールやアップデートで失敗したり、
「名前解決できないんですけど！」と文句を言ってきます。
本番構築する際は、ちゃんとしたDNSサーバなどが存在しているはずなので、
そういった問題に遭遇することが無いでしょうけど、検証環境を社内で構築する。
とかになると、手を抜いちゃうことってありますよね。
「DNSサーバ？面倒くせぇ。hostsファイルで良いだろ？」
それだとvCenterをインストール（デプロイ）するとき、
インストール中のvCenterから名前解決しようとするとのか失敗するんですよ。
そういう経験をしてきたので、今回は予めDNSサーバを用意して、
対象のESXiサーバとvCenterサーバなどのAレコードを準備していたんですね。
そのお陰でvCenterのインストールは問題なく完了！
鼻を高くして検証を進めていたら、
お、おや…？OVFデプロイができない…ウィザードのESXホスト（クラスタ）を選択するところで、
画面が止まってしまう。タスクリストを確認すると失敗している…
「OVFファイルが壊れているのか！？」と考え、別OVFファイルを使っても改善せず。
「では原因はvCenter？」と思いHostClient(ESX単体）で試すと問題なくデプロイ成功。
普段、vCenterはIPアドレスからアクセスしているので、
試しにホスト名でアクセスしてみたところ、デプロイ成功。
……こいつ逆引きしとる！？
DNSサーバにアクセスして逆引き参照ゾーン（PTRレコード）を追加したことで、
IPからアクセスしてもOVFデプロイに失敗することがなくなりました。
いやぁ…DNSサーバ必須ですが、ちゃんと真面目に作らないと駄目なんですね。面倒くせぇ
（ちなみにURL指定からのデプロイの場合はPTRレコード設定していなくてもデプロイ成功するんですよね…）
何はともあれ、vCenter構築するときは、手を抜かずにDNSサーバを構築してから行いましょう！
以下のような事象に遭遇しますよ！
・vCenterインストール時の検証またはインストール途中で失敗する
・vCenterのログインしようとすると無理やりホスト名(FQDN)でリダイレクトされる
・リモートKVM(コンソール）で画面が表示されずにエラーメッセージが表示される。
・OVFデプロイで失敗する