IT or War

 事象 DCUIの機能で管理ネットワーク設定（IPやVLANなど）を設定した後に、サービスリスタートをして再度最初の画面を見てみたら設定が反映されていない、ということがある。 あれれ？とおもって再度設定をしたら、なんだかわけのわからない状態になってしまったということがある。 原因 どうやら、管理ポートのタグを付与されているvmk ポートが複数ある場合、サービス再起動によってDCUIで管理されるポートがトグルされるらしい。 つまり、vmk0とvmk2にManagement Tagがつけられているとして、デフォルトの段階ではvmk0の情報がDCUI上に表示され編集が可能であるが、サービス再起動によってvmk2が管理対象に変わってしまうため、DCUI上でvmk2の情報が表示されるために、設定が反映されていないように見えてしまうということ。 そのため、再設定をした際に想定外の動作や挙動となることがある。 結論 初期設定時などの場合、DCUIからの編集は便利ではあるが、上記のような挙動によって問題を引き起こす場合があるため、ネットワーク設定はesxcli から実施する方が無難。 DCUIから実施する際も、確認作業はesxcli で実施したほうが良い。

 背景 トラブルシューティングの際に、TCPの疎通確認をしたいことは多々あります。TCPの疎通確認といえば、Telnetやcurlコマンドで実施するのが非常に簡単です。  しかし、ESXiには残念ながらこのどちらも含まれておらず、そのほかのマイナーなコマンドやecho >/dev/tcp/<HOST>/<PORT> などでも実施できないため、手段に窮してしまいます。 そこで本記事ではESXiに標準搭載されるpython を利用した確認方法を紹介します      

 背景 過去の記事 でもご紹介していますが、vSAN環境はvSAN7U3 から GUI での Shutdown が可能になっています。 とはいえ、まだまだ旧来の reboot_helper.py を利用したShutdownも行われていると思います。 このスクリプトの中では、PrepareClusterRebootWithNAMM が実行され、その結果によっては、Shutdownが先に進まないことがあります。 例えば、稼働中の 仮想マシンがいる場合や、何らかの理由でUnsupported Host となってしまう場合などです。 reboot_helper.py  の出力から原因がわかればよいのですがそうでない場合は、製品サポート窓口に問い合わせることになるでしょう。 しかしながら、 PrepareClusterRebootWithNAMM を直接実行することで、スクリプトでは切り捨てられている部分のメッセージを確認することができますので、それをきっかけに原因特定につながることもあるかもしれません。 この記事では手動で簡単に PrepareClusterRebootWithNAMM  を実行する方法を紹介します。 手順 ESXiにログインして以下のコマンドを実行してください。 cd /usr/lib/vmware/vsan/bin/ python import reboot_helper vvchs = reboot_helper.ConnectClusterHealthSystem() clusterRef = reboot_helper.vim.ClusterComputeResource('ha-cluster') vvchs.PrepareClusterRebootWithNAMM(clusterRef) 2行目のpython コマンドを実行したタイミングで python の対話モードに入りますが、そのまま以降のコマンドを実行することで、PrepareClusterRebootWithNAMM  を実行し、その結果を直接得ることができます。                 

 なんの役に立つのかわからないが、とりあえず見つけたので備忘めも １．VCにSSHで接続 ２．rvc を起動 ３．rvc で接続先を求められたら接続したユーザとホストを指定。     VCの場合は、administrator@vsphere.local@localhost     ESXiの場合は、 root@<ESXi IP> ４．パスワードを入力して接続完了 ５．ls で 1 のところに localhost or ESXi IPが表示されるのを確認する ６．vsan.debug.mob --start 1 で、vsan mob を有効化する ７． https://<vc or esx ip >/vsan/mob でブラウザから接続可能。 ------ 2022/08/24 補足 ------ ESXi にSSHでログインして、 esxcli vsan debug mob start でも有効化できる模様。

事象 大規模環境かつ、vCenterと連携する 3rd party ソリューション を利用している環境にて、vCenter との HTTPS 疎通を試みた際に、SSL Handshakeがエラーで終了し、vCenterに対し接続やAPIの実行などができない 原因 vSphere 7 以降では、vCenter で２つのリバースプロキシサーバが稼働している。rhttpproxyサービスで構成を管理し、Envoyにてすべての443接続をハンドルしている。 参考： https://docs.vmware.com/jp/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-AC953373-6A18-44A2-A94A-9054C5907090.html Envoyのログを見たところ以下のようになっており、https connection の Limit に達していることが示唆されていた。 #### var/log/vmware/envoy/envoy.log 2022-xx-yyTzz:aa:bb.cccZ warning envoy[3698] [Originator@6876 sub=filter] [C1867905] remote https connections exceed max allowed: 2048 上記から https の上限が2048になっており、上限に達したために SSL 接続がエラーになっていたとわかる 対処 以下は非公式手順なので、正式な手順はサポートに確認してください。 １． VCSAにSSHにてrootユーザでログインする。 ２． /etc/vmware-rhttpproxy/config.xml のファイルの末尾ぐらいにある　L4Filter に以下を追加、もしくは編集して数字を増やす。xxxxxとyyyyyには環境に応じた適切な値を入れてください。 <envoy> <L4Filter> <maxRemoteHttpsConnections>xxxxx</maxRemoteHttpsConnections>　 <maxLocalHttpConnections>yyyyy</maxLocalHttpConn...

  この記事では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で実施可能だったり、別のI...

事象 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