IT or War

 背景 過去の記事 でもご紹介していますが、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       

 事象 VxRail環境など、vSphere 6.x で VCSAとPSCが存在している環境から、vSphere 7.x (PSC無し)にUpgradeした後に、No NSX Manager Available が表示される   また、NSX Manager GUI においても、vCenter/Lookup Serviceとの接続がDisconnected となる 原因 NSX Manager では、Lookup Service と vCenterを別々に登録する必要があり、外部PSC環境においては Lookup Service URL には PSCのFQDNを入力し、vCenter URL には vCenter Server の FQDN を入力する。 vSphere 7.0 にUpgradeすると、PSCがなくなりVCSAだけになるため、NSX Manager の Lookup Service の URL を VCSA の FQDN に書き直す必要がある。     対処 NSX Manager GUI の Edit から Lookup Service URL を編集して PSC から VCSAに書き直せばよい。 修正してから、 NSX Manager / vSphere Client の表示が正常になるまで 5~10分程度かかる場合があるため、Logout/Login などをして待つ。      

SNMPの Version による差異  SNMPにいくつかのVersionがあることはよく知られた事実だと思います。主には、SNMP v1, v2c, v3 が利用されています。 普段利用するうえで、あまり SNMP の Version の細かな違いを意識することは少ないと思います。多くの方は、v1とv2cは認証が不要、v3は認証が必須で設定が面倒、というくらいの差異しか感じていないのではないかと思います。 しかしながら（当然ながら）、それ以外の差異も存在しています。それぞれの詳細な仕様は以下のRFCで規定されています。 SNMP v1 https://datatracker.ietf.org/doc/html/rfc1157 SNMP v2 https://datatracker.ietf.org/doc/html/rfc1905 https://datatracker.ietf.org/doc/html/rfc1910 SNMP v3 https://datatracker.ietf.org/doc/html/rfc3414 上記のRFCを読み解くのは難しいので、詳しく知りたい方は SNMP message format についてググればわかりやすい記事を見つけられると思います。 この Version による差異は、実は SNMP Trap にも存在します。具体的には以下の記事で説明されているように、SNMP v1、v2c であっても PDU の Message format が異なっています。  SNMP v1 Trap PDU Message format http://www.tcpipguide.com/free/t_SNMPVersion1SNMPv1MessageFormat-3.htm SNMP v2 Trap PDU Message format http://www.tcpipguide.com/free/t_SNMPVersion2SNMPv2MessageFormats-5.htm SNMP Trapで利用されるVersionは何か？ ここで疑問に思うのは、SNMP Trap を送信する監視対象デバイスはどの SNMP Version の Trapを送信しているのか、という点です。 SNMP Get などで Pollin...