IT or War

  この記事ではCurlコマンドのみを利用した、ESXiのSSHサービスの有効化方法を示します。 SSHの有効化がコマンド実行毎に必要となる環境の例 実施手法 試験環境 事前準備 有効化のコマンド   SSHの有効化がコマンド実行毎に必要となる環境の例 VMware環境を監視するために、Zabbixなどのアプリケーションを用いて、SSHコマンドを定期的にESXi上で実行したりしている環境はそれなりにあると思います。 SSHコマンドをRemoteから実行するためには、当然ながらESXiでSSHサービスが有効になっている必要があります。 多くの場合はSSHサービスを事前に有効化しておけば問題ないのですが、HCI製品などでSSHサービスの管理が明示的に行えない場合も時折あるかと思います。 たとえば、HCI製品固有の管理用VMがESXi Cluster全体のSSHサービスのOff/Onを動的に実施している場合などです。   そういった環境でZabbixなどの外部サーバから、SSHコマンドによる出力の監視を行いたい、と考えた場合、事前にSSHを有効化しておいたとしても、Systemが自動的にESXiのSSHサービスを無効化してしまい、監視用のコマンドが失敗する、といったことがあり得ます。   もちろんコマンドを実行する前にSSHサービスを都度有効化しさえすれば問題ないのです。 そういったことはPowerCLIやpyvmomiなどを使えば比較的簡単に実施できると思います。 しかしながら場合によってはLinuxで実行する必要があったり（PowerCLI使用不可）、Pythonなどのモジュールを自由に導入できない場合などもあるかと思います。   そういう要件の環境においてCurlコマンドでESXiのSSHを有効化できたら非常に便利かな？と思いましたのでCurlコマンドで実現する方法を紹介いたします。 この記事では結論部分のみを紹介しますが、答えにたどり着くまで（約1時間半）にもいろいろと勉強になることがありましたので、機会があれば紹介したいと思います。     実施手法 今回はMOB経由で実施する方法を選びました。 ちゃんと調べてませんが、もしかしたらVersionによってはRESTAPIで実施可能だったり、別のInterfaceからCurlコマンドのみ実施可能かもしれませんが、今

事象 vSphere 6.x -> 7.0 の Upgrade 後に Deep Security が正常に動作しなくなる。結果として、Upgrade済みのESXiに仮想マシンが起動できなかったり、vMotionできなくなったりしてしまう。仮に起動・移動できてもDRSで即座に戻されてしまう。 Rolling Upgrade の場合、未UpgradeのESXiに仮想マシンが寄せられてしまい、パフォーマンス面で影響が出たり、Upgradeが完了できなかったりする。 原因 以下のKBに該当する事象 Deep Security Virtual Appliance (DSVA) cannot be deployed due to missing platform spec for ESXi https://success.trendmicro.com/dcx/s/solution/1121783-deep-security-virtual-appliance-dsva-cannot-be-deployed-due-to-missing-platform-spec-for-esxi   DeepSecurity側のDeploy設定にvSphere 7.xの場合の記載がないため、7.xになった後正しくDeepSecurityの SVM を展開できていなかった。 対処  KBにある通りに、手動でDeployment Specification に 7.0の記載を追記したら正常に動作する。 ただし、DeepSecurity、NSX、vSphere の互換性には気を付ける必要がある。 互換性については以下から確認可能。 Deep Security and VMware compatibility matrix https://success.trendmicro.com/dcx/s/solution/1060499-deep-security-and-vmware-compatibility-matrix