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

  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを...

この投稿は vExpert Advent Calendarの10日目です。 https://adventar.org/calendars/6689 本記事では以下の状況と、簡易な復旧方法について説明します。 環境 vCSAは自身が管理するvSphere Cluster上に存在する。 vCSAは自身が管理する vDSに接続される vCSAが接続されるdvportgroupはEphemeralではない 該当のvCSA以外にvSphere Clusterを管理できる vCSA は存在しない  障害状況 vCSAは何らかの理由により、もともと存在していたESXiから、別のESXiに再登録されている。 vCSAはvDSから切断されてしまっている。 解説 上記の状況は、ESXiの障害などによって副次的に発生しうる状況です。もともと、vCSA は vDS に接続されていましたが、ESXi の障害などにより、いったん Guest OS から Shutdown され、Host Client を利用して別の ESXi に再登録したうえで起動しています。 この場合、もともとvCSAが接続されていたdvportは別の ESXi 上のポートであるため、起動時にvCSAはvNICを接続することができず、切断状態となります。 vCSAが切断状態になり、かつESXiのHost Clientからは仮想マシンをvDSに接続することができないため（Ephemeral Port を除く）、vCSAの復旧が困難となります。  この状況において有効な解決策としては事前に用意しておいたEphemeral Port を利用するか、もしくは一時的にVSSを作成して復旧する方法が一般的な方法です。 事前にEphemeral Port の準備がない場合には、VSSを作成することになりますが、Uplinkに空きがない場合は、Uplinkを付け替える必要があり、手順は複雑になります。 今回はVSSを利用しない簡易な復旧方法についてご紹介します。 簡易な復旧方法 完結に手順を示すと以下です。 vNICが切断されているVCSAをShutdown  vCSAが存在する ESXi を Maintenance Mode～Reboot  vCSA を再度起動～vNICが接続状態であることを確認...

 vSAN 7U3 での Shutdownに関するエンハンスメント 何が変わったか それまで煩雑だったvSAN Cluster の Shutdown 手順が vSAN 7U3 の新機能によって簡易化されました。 参考： https://core.vmware.com/blog/vsan-7-update-3-whats-new    従来のやり方（Manual Shutdown）では、vSAN Cluster上のすべての仮想マシンを停止したのちに、ESXiをメンテナンスモードに入れる前に、手動でScriptを実行する必要がありました。 また、PowerUp の際も、ESXi をメンテナンスモード解除した後で、同様に手動で Script を実行する必要がありました。vSAN 6.7U3 より未満の Version では、すべての ESXi でこれを実施しなくてはならず、かつ Script も VMware のサイトからダウンロードし全 ESXi に配置し、かつそれを時刻同期した状態で Cron で実行する必要がありました。 vSAN 6.7U3 以降では、Script が更改され、自動化が進み、かつデフォルトで ESXi に内蔵されました。しかも、vSAN Cluster 内の任意の1ホストで実行するだけでよいため、それまでと比べて非常に簡易化されましたが、依然として CLI ベースの対応が必要であり、エンドユーザにとっては難しい場合もありました。 今回の vSAN 7.0 U3 では、従来の CLI ベースの Shutdown 手順から、GUI での Shutdown が可能になりました。自動化も大きく進み、Shutdown と PowerUp の両手順において、わずか数クリックで完了できます。 そもそもなぜ CLI ベースの Shutdown が必要だったか。 vSAN には、以下の KB で説明される不具合があり、過去すべての Version で該当します。この不具合は2018年に報告されていますが、最新版でも直っていません。 A simultaneous reboot of all hosts in the vSAN cluster may result in data unavailability after a sin...