ESXiでのパケットキャプチャでハマったこと
１．はじめに
仕事でちょっと障害があってESXiでパケットキャプチャを取る機会がありました。 その際にハマったことを紹介いたします。
２．発生した問題
「ESXi上のVMでネットワーク通信が突然できなくなる場合がある」というものです。 整理すると次の通りです。
３．最初の切り分け
VM利用者からは通信できてないので「なんとかせい！」となり、仮想基盤やVM（ゲストOS）での調査や対応を行いました。
３．１．仮想基盤での対応
まずは手探りで下記を実施しました。
- VMの設定でvNICの切断/接続
- vMotionで別のESXiに移行
これで回復した場合もありましたが、しばらくして再発したりもして、VM利用者の温度感がかなり上がってしまいました。
何とかしなければと頭をひねり、同じポートグループのVM間の通信については、同じESXiにVMを収容 してみたところ、VM間の通信は回復しました。
これにより、ESXiのアップリンクを出てネットワーク機器にトラフィックが流れると通信できない場合がある とわかりました（ネットワーク機器が事象の原因である可能性が高いとの仮説）。
３．２．VM（ゲストOS）での調査
事象発生しているVM（ゲストOS）でtcpdumpを取ってみたところ、ARPのリクエストは出しているがリプライがない ことがわかりました。
また、ARPリクエストを投げないように、ゲストOSで スタティックMACの設定 （このIPのMACアドレスはこれですって設定）を入れると、VM間通信もゲートウェイへの通信もできることを確認できました。
これで、ARP解決ができていないことが原因であるとわかりました。
３．３．ネットワーク担当を交えた議論
同じESXiに2台のVMを配置してVM間通信だと問題なく出来るようになるということは
ということになります。
であれば「ネットワーク機器が事象の原因である可能性が高いのではないか？」とネットワーク担当に申し上げました。
ネットワーク担当者から「VMから出ているARPリクエストがESXiのアップリンクからも出ているかを確認してほしい」となりました。
- 出ているなら、ネットワーク機器が起因である可能性が高くなる
- 出ていないなら、ESXiのソフトウェア的な不具合である可能性が高くなる
そこで、ESXiでパケットキャプチャすることになりました。
４．パケットキャプチャを取ってみた
pktcap-uw コマンドを使いました。
障害が起きた環境のESXiは2本の10Gbpsのアップリンクがあります（vmnic0, vmnic1）。
事象発生しているVM（ゲストOS）でデフォルトゲートウェイアドレスにpingを打ちながら、ESXiのアップリンクの1本ずつ順番にパケットキャプチャを取りました。
pktcap-uw --outfile vmnic0.cap --uplink vmnic0 pktcap-uw --outfile vmnic1.cap --uplink vmnic1
あれ？どちらのキャプチャファイルにもゲストOSから出ているARPリクエストが見当たらない！！！ これだと、ネットワーク機器の不具合というよりは ESXiのソフトウェア的な不具合の可能性が高くなるのか？ ということで、当初立てた仮説と違う結果に頭が混乱しました。
５．ARPパケットの行方判明！
そこで、基本に立ち返り、pktcap-uwコマンドの使い方が間違って可能性 を疑って下記を調べてみました。
dir オプションというのがあり、デフォルトが受信トラフィックしかキャプチャされない とのことでした！ 今回特に確認したいのは 送信トラフィック だろ！
そもそも 何でデフォルトが受信トラフィックのみなんだろうか？ とは思いつつ、dirオプションで 双方向トラフィックを指定してパケットキャプチャをし直しました。
pktcap-uw --outfile vmnic0.cap --dir 2 --uplink vmnic0 pktcap-uw --outfile vmnic1.cap --dir 2 --uplink vmnic1
- vmnic1のほうは、事象発生したVMからのpingに伴うARPリクエストのパケットが確認できました
- vmnic0のほうは、事象発生していないVMのARPリクエスト/リプライが確認できました
- 事象発生したVMからのARPリクエストに対するARPリプライは、vmnic0/vmnic1のどちらでも確認できませんでした
ということで、vminc1の経路が怪しそうだということがわかりました。
これで、事象の原因がネットワーク起因の可能性が高くなったので、ネットワーク担当の方の調査に移行しました。 ESXiのvmnic1の上位スイッチでのパケットキャプチャを何か所かでやってもらう予定です。
６．おわりに
本事象はまだ解決してはおらず、対応中です。 「ハマったら基本に立ち戻る」 というのは、やはり大事であると再認識しました。
解決したら続編を書きたいと思います。
※ 本記事で記載されている会社名、製品名は、各社の登録商標または商標です。
７．お知らせ
VMwareユーザ会（VMUG）に興味のある方は、
https://www.vmug.com/membership/membership-benefits
から入会していただけると幸いです。 イベントでお会いできるのを楽しみにしております。
以上です。
Linux版PowerCLIの文字化け
はじめに
スズケンです。vExperts Advent Calendar 2020 12/12の投稿になります。
前回Linux版PowerCLIのインストールについて書きました。
今回は、その後会社でインストールしてみて、ハマった小ネタを書いてみたいと思います。
■家ではうまくいったのに・・・
会社でLinux版PowerCLIを入れるべく、まずPowerShellをインストールしたところ、PowerShellコマンドプロンプトでのコマンドの入力が化けるという事象が発生しました（下記は、自宅で事象を再現させた際の画面）。
おかしいなぁ。なぜ化ける？lsと打っただけなのに。
決め打ちで入力したコマンドの結果は、ちゃんと文字化けせずに表示されるんですよね。 入力した文字列自体はちゃんと認識してくれていることは確かです。
Puttyの設定か？文字コードか？UTF8以外も試したけど、状況は何も変わりませんでした。
文字コード以外のPutty設定を色々変えてみたけど、関係なさそうでした。
結局、会社と自宅のPutty設定を全部比較したけど、差が見つかりませんでした。
■ちょっと切り分けが進む
切り分けで、WebClientでLinux版PowerShellを入れたVMにコンソール接続してみると、文字化けしないことがわかりました。
だとすると、PowerShellのセットアップ自体は上手くいっているということがわかりました。
事象の内容が、「ssh接続でpwshのコマンドプロンプトでの入力文字列が化ける」ということが明確になってきました。 そういや、入力文字列って正しく表示されるときには色付きだなぁと。ssh接続の時はその辺がうまくいかずに化けるのかなと。
とにかく、端末の設定の何かが悪いのだろうとは思いましたが、なかなか原因特定には至りませんでした。 文字化けしない自宅環境と会社環境でPuttyの設定に差がないのも確認したので、Putty設定以外の何かなんだろうと。
■問題解決
Linuxに詳しい私の部下があっさり解決してくれました。
何ということでしょう。
会社環境では、TERM=vt100 が標準設定になっていたのが原因でした。 これを、TERM=xterm に変更しただけで、文字化けは解消されました。
この情報を得て、文字化けしていなかった自宅環境でTERM=vt100で試したら、見事に事象が再現したのです。 （自宅環境のTERMは、デフォルトでxterm-256colorになってました）
※下記、どちらもlsと打った後、exitでpwshを抜けただけの操作になります
これでPowershell Server（Windows版）をLinux版PowerCLIに運用を切り替える道筋がつきました。 良かったです。
ただ、「TERM=vt100にしている人って世間でどれだけいるんだろうか？」という疑問は湧きました。うちの会社の場合、X-Window系のGUIは使ってないので、TERMをvt100にしているってことなんだろうとは思いますが。
私が見逃しているだけで、ひょっとしたら「Linux版PowerShellを使う場合は、環境変数TERMはvt100ではNGです」って情報がどこかに書いてあったりしたのかなぁ（もし知っている方が居たら教えていただきたいです）。
■終わりに
意外なところに落とし穴があり、思いの外あっさり解決されてしまうものだと思いました。部下のskmtさんには感謝です。 私自身のLinuxの知識の浅さが露呈し、もっと勉強しなければいけないなと思った次第です。
改めて、環境変数TERMの役割を再認識をしたところで、話を終わりたいと思います。
12/6は、CJ さんの記事になります。
※ 本記事で記載されている会社名、製品名は、各社の登録商標または商標です。
■お知らせ
VMwareユーザ会（VMUG）に興味のある方は、
https://www.vmug.com/membership/membership-benefits
から入会していただけると幸いです。 部会でお会いできるのを楽しみにしております。
以上です。
Linux版PowerCLIのインストール
はじめに
スズケンです。久々の投稿です。
今回は、Linux版PowerCLIのインストールについて書きたいと思います。
■前提
今回は、会社環境でよくありがちな、インターネットにつながっていない環境でのLinux版PowerCLIを想定して、インストール方法を試行錯誤してみました。
■Powershellのインストール
まずは、Powershellを入れてみます。 インターネットにつながる環境で、下記サイトからrpmをダウンロードします。
https://packages.microsoft.com/rhel/7/prod/
[root@localhost ~]# rpm -ivh powershell-lts-7.0.3-1.rhel.7.x86_64.rpm [root@localhost ~]# rpm -qa | grep powershell powershell-lts-7.0.3-1.rhel.7.x86_64
※ltsが付くパッケージ名のものは、rpmインストール時にダウンロード不要なもののようです。
■Powershellの起動
Powershellを起動できました。
[root@localhost ~]# pwsh PowerShell 7.0.3 Copyright (c) Microsoft Corporation. All rights reserved. https://aka.ms/powershell Type 'help' to get help. PS /root>
利用可能なモジュールを確認してみます。
PS /root> Get-Module -ListAvailable Directory: /opt/microsoft/powershell/7-lts/Modules ModuleType Version PreRelease Name PSEdition ---------- ------- ---------- ---- --------- Manifest 1.2.5 Microsoft.PowerShell.Archive Desk Manifest 7.0.0.0 Microsoft.PowerShell.Host Core Manifest 7.0.0.0 Microsoft.PowerShell.Management Core Manifest 7.0.0.0 Microsoft.PowerShell.Security Core Manifest 7.0.0.0 Microsoft.PowerShell.Utility Core Script 1.4.7 PackageManagement Desk Script 2.2.4.1 PowerShellGet Desk Script 2.0.5 PSDesiredStateConfiguration Core Script 2.0.2 PSReadLine Desk Binary 2.0.3 ThreadJob Desk
■PowerCLIのインストール準備
インターネットにつながらない環境でのPowerCLIのインストールをするとなると、通常のInstall-Moludeコマンドは使えません。 まずは、インターネットにつながる環境で、PowerCLIのモジュールを入手すべく、Save-ModuleコマンドでPowerCLIのモジュールをダウンロードします。
ダウンロード先のディレクトリを作成します。
PS /root> mkdir powershell
PowerCLI用のモジュールファイルをダウンロードします。
PS /root> Save-Module -Name VMware.PowerCLI -Path ./powershell/
tar.gzファイルに固めます。
PS /root> cd ./powershell/ PS /root/powershell> ls -l 0 drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.CloudServices drwxr-xr-x. 3 root root 28 10 24 21:35 VMware.DeployAutomation drwxr-xr-x. 3 root root 28 10 24 21:35 VMware.ImageBuilder drwxr-xr-x. 3 root root 29 10 24 21:35 VMware.PowerCLI drwxr-xr-x. 3 root root 28 10 24 21:34 VMware.Vim drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Cis.Core drwxr-xr-x. 3 root root 29 10 24 21:35 VMware.VimAutomation.Cloud drwxr-xr-x. 3 root root 29 10 24 21:33 VMware.VimAutomation.Common drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Core drwxr-xr-x. 3 root root 29 10 24 21:35 VMware.VimAutomation.Hcx drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.HorizonView drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.License drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Nsxt drwxr-xr-x. 3 root root 29 10 24 21:33 VMware.VimAutomation.Sdk drwxr-xr-x. 3 root root 29 10 24 21:35 VMware.VimAutomation.Security drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Srm drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Storage drwxr-xr-x. 3 root root 21 10 24 21:35 VMware.VimAutomation.StorageUtility drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Vds drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.Vmc drwxr-xr-x. 3 root root 29 10 24 21:35 VMware.VimAutomation.WorkloadManagement drwxr-xr-x. 3 root root 29 10 24 21:34 VMware.VimAutomation.vROps drwxr-xr-x. 3 root root 29 10 24 21:35 VMware.VumAutomation
tarファイルで固めます。
PS /root/powershell> tar cf powercli.tar ./VMware.* PS /root/powershell> gzip ./powercli.tar PS /root/powershell> ls -l ./powercli.tar.gz -rw-r--r--. 1 root root 67183865 10月 24 22:49 ./powercli.tar.gz
■PowerCLIのインストール（モジュールの配置）
tar.gzファイルをインストールしたい環境に持ってきます（ここの手順は脳内で補完してください）。
持ってきたファイルを展開する場所は、下記コマンドのパスのうち、/usr/local/share/powershell/Modules に置くことにします。
PS /root> $Env:PSModulePath /root/.local/share/powershell/Modules:/usr/local/share/powershell/Modules:/opt/microsoft/powershell/7/Modules
持ってきたファイルを展開します。
PS /root> mkdir /usr/local/share/powershell/Modules PS /root> PS /root> cd /usr/local/share/powershell/Modules PS /usr/local/share/powershell/Modules> PS /usr/local/share/powershell/Modules> ls -l ./powercli.tar.gz -rw-r--r--. 1 root root 67183865 10月 24 22:49 ./powercli.tar.gz PS /usr/local/share/powershell/Modules> PS /usr/local/share/powershell/Modules> gunzip ./powercli.tar.gz PS /usr/local/share/powershell/Modules> PS /usr/local/share/powershell/Modules> ls -l ./powercli.tar -rw-r--r--. 1 root root 350105600 10月 24 22:49 ./powercli.tar PS /usr/local/share/powershell/Modules> PS /usr/local/share/powershell/Modules> tar xf ./powercli.tar
あと、おまじないで下記を実行します。
PS /usr/local/share/powershell/Modules> Set-PowerCLIConfiguration -InvalidCertificateAction Ignore Perform operation? Performing operation 'Update PowerCLI configuration.'? [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): Scope ProxyPolicy DefaultVIServerMode InvalidCertificateAction DisplayD eprecati onWarnin gs ----- ----------- ------------------- ------------------------ -------- Session UseSystemProxy Multiple Ignore True User Ignore AllUsers
PS /usr/local/share/powershell/Modules> Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false Perform operation? Performing operation 'Update PowerCLI configuration.'? [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): Scope ProxyPolicy DefaultVIServerMode InvalidCertificateAction DisplayD eprecati onWarnin gs ----- ----------- ------------------- ------------------------ -------- Session UseSystemProxy Multiple Ignore True User Ignore AllUsers
■PowerCLIモジュール配置後の確認
モジュールを/usr/local/share/powershell/Modulesに配置した後、有効なモジュールを再確認してみます。
PS /usr/local/share/powershell/Modules> Get-Module -ListAvailable Directory: /usr/local/share/powershell/Modules ModuleType Version PreRelease Name PSEdition ---------- ------- ---------- ---- --------- Script 12.1.0.17 VMware.CloudServices Desk Script 7.0.0.159 VMware.DeployAutomation Desk Script 7.0.0.159 VMware.ImageBuilder Desk Script 7.0.1.169 VMware.Vim Desk Script 12.1.0.16 VMware.VimAutomation.Cis.Core Desk Script 12.0.0.15 VMware.VimAutomation.Cloud Desk Script 12.1.0.16 VMware.VimAutomation.Common Desk Script 12.1.0.16 VMware.VimAutomation.Core Desk Script 12.1.0.17 VMware.VimAutomation.Hcx Desk Script 7.13.0.16 VMware.VimAutomation.HorizonView Desk Script 12.0.0.15 VMware.VimAutomation.License Desk Script 12.0.0.15 VMware.VimAutomation.Nsxt Desk Script 12.1.0.16 VMware.VimAutomation.Sdk Desk Script 12.1.0.17 VMware.VimAutomation.Security Desk Script 12.1.0.17 VMware.VimAutomation.Srm Desk Script 12.1.0.17 VMware.VimAutomation.Storage Desk Script 1.6.0.0 VMware.VimAutomation.StorageUtility Desk Script 12.1.0.17 VMware.VimAutomation.Vds Desk Script 12.1.0.17 VMware.VimAutomation.Vmc Desk Script 12.0.0.15 VMware.VimAutomation.vROps Desk Script 12.1.0.17 VMware.VimAutomation.WorkloadManag Desk Script 12.1.0.16 VMware.VumAutomation Desk Directory: /opt/microsoft/powershell/7-lts/Modules ModuleType Version PreRelease Name PSEdition ---------- ------- ---------- ---- --------- Manifest 1.2.5 Microsoft.PowerShell.Archive Desk Manifest 7.0.0.0 Microsoft.PowerShell.Host Core Manifest 7.0.0.0 Microsoft.PowerShell.Management Core Manifest 7.0.0.0 Microsoft.PowerShell.Security Core Manifest 7.0.0.0 Microsoft.PowerShell.Utility Core Script 1.4.7 PackageManagement Desk Script 2.2.4.1 PowerShellGet Desk Script 2.0.5 PSDesiredStateConfiguration Core Script 2.0.2 PSReadLine Desk Binary 2.0.3 ThreadJob Desk
ちゃんと、PowerCLIのモジュールが認識されているようですね。
■PowerCLIコマンドレットの動作確認
私の家の環境だと、vCenterやNestedのESXiを立ち上げられるほどの余力がないため、コマンドが動くかどうか（vCenterにつながっていないというエラーが出るかどうか）を確認するまでに留めます。
試しに、Get-VMHostコマンドレットを実行してみます。
PS /root> Get-VMHost Get-VMHost: 2020/10/25 0:41:10 Get-VMHost You are not currently connected to any servers. Please connect first using a Connect cmdlet.
想定通り、vCenterとつながっていない時に出るエラーメッセージが出ました。
■おわりに
インターネットにつながっていない環境でも、Linux版PowerCLIをインストールすることができました。 会社環境でセキュリティ要件が厳しくても、このような感じでLinuxの管理サーバ等でPowerCLIを利用することはできそうです。 参考になれば幸いです。
■参考にした情報
VMRC11.Xの仕様変更にご注意を
スズケンです。久々の投稿です。
今回は、仕事でハマったネタを書いてみたいと思います。
■発端
仮想基盤の管理者は通常WebClientを使っていますが、仮想マシンの利用者向けのインターフェイスとしては多機能すぎます。権限を仮想マシンに限定したとしても、仮想マシンの利用者に使わせるには見えてほしくない情報とかも見えてしまいます（タスクとかイベントとか）。
そこで、一部の仮想マシン利用者向けにコンソール機能を提供するVMRCというプログラムを利用しています。
VMRCにより、仮想マシンに対するコンソール接続、電源操作、CDマウント機能に限定して、利用者に提供をしております。
今回は、そのVMRCのセキュリティ脆弱性対応をするところから話が始まります。
■対応すべきセキュリティ脆弱性
昨今、セキュリティ脆弱性対応をやらないことで万が一問題が出てしまうと、会社の信頼失墜につながるため、セキュリティ脆弱性が出る都度、弊社で影響があるかどうか？対応が必要がどうかについて早急に検討をし、対応が必要となったら、なる早で対応が求められております。
今回対応すべきセキュリティ脆弱性は、VMSA-2020-0004というものになります。下記、2020/3/12にVMware社から発行されたものになります。
3c. VMware Horizon Client, VMRC and Workstation privilege escalation vulnerability (CVE-2019-5543)
が対応すべきと判断した部分となります。これにより、VMRCというコンソール接続のためのプログラムを11.0以降にしないといけないことが分かりました。 仮想マシン利用者が使っているVMRCから権限昇格されるリスクがあるため、対応することにしました。
■あれ？おかしいぞ？
検証を始めると、どうもVMRCを11.0にすると、仮想マシンへのコンソール接続が出来なくなっていることが分かりました。 いろいろ調査や試行錯誤をしていると、下記情報にたどり着きました。
あれ？使用するポートが、902/tcpから443/tcpに変わったのか！ということが分かりました。 え、そんな仕様変更、シレっとされるのは辛いぞ！と思いました。
VMRC11.0のリリースノートを見てみても、使用するポートが変更になるなんて、一言も書いてないし。。。
11.0.1（Mac版）や11.1.0のリリースノートには、このように書いてありました。
VMware Remote Console 11.0.1 では、ESXi ホストのポート 443 への直接アクセスが必要になります。詳細については、VMware ナレッジベースの記事 KB76672 を参照してください。
ここで、既に見つけていたKBの情報を照合できました。
■仕様変更に従ってやってみる
早速ネットワーク機器で、ESXホストへの443/tcpの穴あけを実施し、無事コンソール接続ができることを確認しました。
4月下旬に、なんとかセキュリティ脆弱性対応が完了しました。 902/tcpは、セキュリティ強化の見地からネットワーク機器で閉塞しました（今回のセキュリティ脆弱性に902/tcpが関連しているのでは？という推測もあり）。
■とある利用者からの申告
5月下旬になって、ある利用者の仮想マシンが、ESXホストのサーバHW故障でvSphereHAで再起動した際に破損したようで、NWにつながらなくなったとのことでした。 どうやら、ゲストOS的に壊れてしまったようです。仮想マシンの仮想HWとしては問題ない状態でした。
この仮想マシンを復旧するためには、利用者が取ったバックアップをリストアする必要があります。 ここで、コンソール機能でバックアップソフトのBootCDからの起動を行い、システムリストアするという流れになりますが、なんとVMRCでCDマウントできない状況になっておりました。
すぐに、関係者が集まり（このご時世なのでリモートで）、原因を議論している中、「まさか、CDマウントだけ従来の902/tcpを使ってたりしないよねぇ？」という推測に至りました。
試しに、評価環境の仮想マシンに対してコンソール接続をし、そこでCDマウントを試みてみた状態で、DOSプロンプトでnetstatを実行すると、
> netstat -ant | findstr ESXホストのIP TCP PCのIP:52949 ESXホストのIP:443 ESTABLISHED ???? TCP PCのIP:53077 ESXホストのIP:902 SYN_SENT ????
ってことで、902/tcpに通信しに行っているじゃないですか！
急いでネットワーク機器で902/tcpの穴あけをしたら、VMRCでCDマウントできるようになりました。
穴あけ後のnetstatはこんな感じでした。
> netstat -ant | findstr ESXホストのIP TCP PCのIP:59073 ESXホストのIP:443 ESTABLISHED ???? TCP PCのIP:59191 ESXホストのIP:902 ESTABLISHED ???? ★
ちゃんと通信できていることを確認できました。 利用者が仮想マシンのリカバリで急いでいるときに足を引っ張ってしまって、大変申し訳なかったと思っております。
■反省
今回、KBの情報を見て、使用するポートが902/tcp → 443/tcp に変更になって、旧ポートは使わなくなると思い込んでしまって、CDマウントの動作確認を端折ってしまったことが敗因でした。 まさか一部機能だけ旧ポートを使うという罠があるとは思わなかったです（言い訳）。
コンソール機能は、仮想マシンが壊れたりした際に使うことが多い機能で、いざってときに動かないのはまずいため、CDマウント機能の動作確認がとても大事だと痛感しました。
今回のような使用ポートが変わるような大きめの仕様変更がある場合は、使用している機能については漏れなくテストをするなどの対応が必要であるということに尽きると思います。 大変お恥ずかしい例で恐縮でしたが、テストが大事だという1つの例として、皆様への注意喚起に役に立てば幸いです。
■後日談
VMware社に再度確認をしたところ、VMRC11.0以降が通信で使うポートが、接続先ESXホストのバージョンによって異なるとのことでした。使用されるvSphereバージョン、VMRCバージョンでも動作が異なるので注意が必要です。
VMRC11.0の場合
| 項番 | 通信 | vSphere6.X | vSphere7.0 |
|---|---|---|---|
| ① | vCenter, ESXiとの管理用通信 | 443 | 443 |
| ② | 仮想マシンを操作するMKS通信 | 443 | 443 |
| ③ | isoイメージなどのリモートデバイス用のNFC通信 | 902 | 902 |
VMRC11.1の場合
| 項番 | 通信 | vSphere6.X | vSphere7.0 |
|---|---|---|---|
| ① | vCenter, ESXiとの管理用通信 | 443 | 443 |
| ② | 仮想マシンを操作するMKS通信 | 443 | 443 |
| ③ | isoイメージなどのリモートデバイス用のNFC通信 | 902 | 443 |
※ 本記事で記載されている会社名、製品名は、各社の登録商標または商標です。
■お知らせ
VMwareユーザ会（VMUG）に興味のある方は、
https://www.vmug.com/membership/membership-benefits
から入会していただけると幸いです。 部会でお会いできるのを楽しみにしております。
以上です。
VMware Toolsの置き場変更
ずいぶんとマニアックな内容になりますが、VMware Toolsの置き場変更についてです。
目的
ESXホストのパッチ適用時期の差で、ESXホストの腹の中のToolsバージョンに違いが出るのを避け、vMotionで移動した前と後でVMで使っているToolsのStatusがCurrent/Old/OutOfDate等の判定がズレるのを避けるのが目的です。
ESXの詳細パラメータ変更
ESXホストの詳細パラメータ（UserVars.ProductLockerLocation）の変更をすると、デフォルトのESXホストの腹の中ではなく、共有ストレージ（データストア）上にVMware Toolsを置くことができます。
ESXホストの再起動は必要か？
UserVars.ProductLockerLocationの変更の反映のためにESXの再起動が必要とされていますが、実はESXホスト上のシンボリックリンク張り替えをすることで、ESXホストの再起動をしないでも済ませることがわかりました。ESXホストは起動時、UserVars.ProductLockerLocationの値を参照先として毎回シンボリックリンクを作り直してるようです。
# ls -l | grep productLocker lrwxrwxrwx 1 root root 22 Apr 17 12:00 productLocker -> /locker/packages/6.0.0 # # rm /productLocker # # ln -s /vmfs/volumes/datastorename/locker/packages /productLocker lrwxrwxrwx 1 root root 42 Apr 17 22:41 productLocker -> /vmfs/volumes/datastorename/locker/packages
まとめ
今回は、ストレージ装置のリプレースでVMware Toolsの置き場を変えたかったのですが、なんとかESXの全台のリブートする作業は避けたかったので、この方法が見つかってよかったです（台数が結構あったので）。
詳細は、こちらのURLのKBに記載があります。 https://kb.vmware.com/s/article/1037405?lang=ja
以上です。
PowerNSXインストール＆使用例
はじめに
本記事は、vExperts Advent Calendar 2019 の 12月4日 分の投稿になります。
vExperts Advent Calendarには今回初参戦のスズケンと申します。よろしくお願いいたします。
PowerNSXとは
端的に言えば、NSX-V用のコマンドレット群です。
NSX-TはPowerCLIに標準装備なのですが、NSX-Vはそうではありません。
そこでPowerNSXを入れることで、補完します。
弊社では、NSXのログ等の調査で、セキュリティグループ名とオブジェクトIDの対応付けを知りたくて入れてみました。
PowerNSXのインストール
1) https://github.com/vmware/powernsxにアクセス
弊社の場合、プロキシの設定が厳しくてオンラインでのインストールはできなかったため、オフラインでのインストールを試みました。
弊社と同じようにプロキシのアクセス不許可に引っかかった場合は、下記のやり方が参考になるかと思います。
2) ZIPファイルをダウンロード
3) ZIPファイルを解凍
4) モジュールの手動インストール
PowerCLI C:\> Import-Module C:\Users\*********\Desktop\powernsx-master\module\platform\desktop\PowerNSX\PowerNSX.psd1
5) vCenterと接続
PowerCLI C:\> Connect-VIServer XXX.XXX.XXX.XXX Name Port User ---- ---- ---- XXX.XXX.XXX.XXX 443 USERNAME
※XXX.XXX.XXX.XXX：vCenterのIPアドレス
6) NSX Managerと接続
PowerCLI C:\> Connect-NsxServer -NsxServer YYY.YYY.YYY.YYY -Username admin -Password ******** Using existing PowerCLI connection to XXX.XXX.XXX.XXX Version : 6.3.4 BuildNumber : 7087695 Credential : System.Management.Automation.PSCredential Server : YYY.YYY.YYY.YYY Port : 443 Protocol : https UriPrefix : ValidateCertificate : False VIConnection : XXX.XXX.XXX.XXX DebugLogging : False DebugLogfile : C:\Users\*********\AppData\Local\Temp\PowerNSXLog-admin@YYY.YYY.YYY.YYY-2019_MM_DD_hh_mm_ss.log
※YYY.YYY.YYY.YYY：NSX ManagerのIPアドレス
PowerCLIをちょっと使ってみる
セキュリティグループの検索をやってみる
PowerCLI C:\> Get-NsxSecurityGroup | select name, objectid | where { $_.name -match "552c9386-3adb-4bf6-99f1-5cbb7f606aec"}
name objectId
---- --------
000000001801_552c9386-3adb-4bf6-99f1-5cbb7f606aec securitygroup-2662
補足情報
詳細は下記URLをご参照ください。
https://powernsx.github.io/get-started
おわりに
以上、PowerNSXインストールと使用例でした。 明日は、Kan Chiyodaさんの記事です。お楽しみに！
