ゲスト イントロスペクション シン エージェントは、各ゲスト仮想マシンに VMware Tools™ とともにインストールされます。

Linux でのシン エージェントのトラブルシューティング

仮想マシンでの読み取り/書き込み処理、ファイルの解凍または保存に時間がかかる場合は、シン エージェントに問題がある可能性があります。

  1. 関連するすべてのコンポーネントの互換性を確認します。ESXi、vCenter Server、NSX Manager、選択したセキュリティ ソリューション（Trend Micro、McAfee、Kaspersky、Symantec など）のビルド番号が必要です。このデータを収集して、vSphere コンポーネントの互換性を比較します。詳細については、VMware 製品互換性マトリクスを参照してください。
  2. システムにファイル イントロスペクションがインストールされていることを確認します。
  3. systemctl status vsepd.service コマンドを実行して、シン エージェントが実行されていることを確認します。
  4. パフォーマンス問題の原因がシン エージェントにあると思われる場合は、service vsepd stop コマンドを実行してサービスを停止します。
  5. テストを実行して、ベースラインを取得します。vsep サービスを開始した後で、service vsepd start コマンドで別のテストを実行できます。
  6. ネットワーク イベントを使用する展開の場合は、systemctcl status vmw_conn_notifyd.service を実行して vmw_conn_notify も確認する必要があります。
  7. Linux シン エージェントのデバッグを有効にします。
    1. /etc/vsep/vseprefresh-logging を実行します。
    2. 使用方法：/etc/vsep/vsepd refresh-logging <dest> <<level> sub-component-name>

      ここで、<dest>：[1-2] 1 - 仮想マシンにログを記録する。2 - ESX ホストにログを記録する。

      <level>：[1-7]、4 はログ レベル INFO、7 はログ レベル DEBUG。

      <sub-component-name>：1 つ以上の転送、タイマー、ファイル、ネットワーク、プロセス、システム。

      ホストへのログ記録が有効になっている場合、ログは、ESXi ホスト上の仮想マシンの各 vmfs ディレクトリの vmware.log に保存されます。

      注： 完全なログ作成を有効にすると、大量のログ アクティビティが発生し、 vmware.log ファイルがいっぱいになる可能性があります。完全なログ作成は、できるだけ早く無効にしてください。

コンテキスト（ファイル、プロセス、ネットワーク、またはシステム）に基づくデバッグの有効化

ログのサポート強化により、シン エージェントは特定の機能のモジュール デバッグ レベル情報をホストの vmware.log または仮想マシンの Syslog に記録できるようになりました。

デバッグ ログがこれらファイルに生成されない場合は、シン エージェント サービスを再起動する必要があります。ログが大量に記録されると、ホスト上の vmware.log に対するログ記録が調整される場合があります。/etc/vsep/vsepd に refresh-logging 入力パラメータが追加されました。次のコマンドを実行すると、使用方法が表示されます。

デバッグ：

# /etc/vsep/vsepd refresh-logging

使用方法：/etc/vsep/vsepd refresh-logging <dest> <<level> sub-component-name>

ここで、<dest>：[1-2]：1 は、仮想マシンにログを記録します。2 は、ESX ホストにログを記録します。仮想マシンへのログ記録が有効になっている場合、ログは Linux ディストリビューション ソフトウェアに基づいて次の場所に保存されます。

Ubuntu 仮想マシン：/var/log/syslog

CentOS、RHEL、SLES：/var/log/messages

ホストへのログ記録が有効になっている場合、ログは ESXi ホスト上の仮想マシンの各 vmfs ディレクトリの vmware.log に保存されます。

<level>：[1-7]、4 はログ レベル INFO、7 はログ レベル DEBUG です。

<sub-component-name>：1 つ以上の転送、タイマー、ファイル、ネットワーク、プロセス、システム。

例：

次のコマンドを有効にすると、そのコンテキストからのログのみが出力されます。

次のコマンドを使用すると、ネットワーク イントロスペクションのデバッグ ログを有効にできます。

/etc/vsep/vsepd refresh-logging 1 7 network

プロセス イントロスペクションのデバッグ ログ：

/etc/vsep/vsepd refresh-logging 1 7 process

アンチウイルスの使用事例のデバッグ ログ：

/etc/vsep/vsepd refresh-logging 1 7 file

タイマー コンテキストでのコマンド処理（すべての使用事例）：

/etc/vsep/vsepd refresh-logging 1 7 timer

ユーザー モニタリング：

/etc/vsep/vsepd refresh-logging 1 7 system

SVM とコンテキスト Mux 間のフレームワーク通信（すべての使用事例）：

/etc/vsep/vsepd refresh-logging 1 7 transport

Linux でのシン エージェント クラッシュのトラブルシューティング

シン エージェントは、クラッシュ時にコア ダンプを生成します。ただし、これはオペレーティング システムのコア ダンプの構成によって異なります。Linux ディストリビューションごとに、システム クラッシュ時のコア ダンプの生成方法と構成が異なります。

たとえば、アプリケーションには apport を使用してクラッシュ時にコア ダンプを生成できますが、Red Hat の場合は abrtd を使用します。ただし、シン エージェントは、ログ記録の出力先に応じて、仮想マシンの /var/log/syslog (Ubuntu) または /var/log/messages（CentOS、RHEL、SLES）か、vmware.log（ホストでログ記録が有効になっている場合）にバックトレースをダンプします。

サンプル バックトレース：

localhost systemd: Started Session 4 of user root.
localhost vsep: EMERG: 0: sig_handler(): Received signal: 11
localhost vsep: EMERG: 0: sig_handler(): backtrace returned 7 pointers
localhost vsep: EMERG: 0: sig_handler(): /usr/sbin/vsep(+0x1d35e) [0x7fa2e4c9135e]
localhost vsep: EMERG: 0: sig_handler(): /lib64/libc.so.6(+0x35a00) [0x7fa2e3d76a00]
localhost vsep: EMERG: 0: sig_handler(): /usr/sbin/vsep(+0x3f789) [0x7fa2e4cb3789]
localhost vsep: EMERG: 0: sig_handler(): /lib64/libglib-2.0.so.0(+0x6e0fc) [0x7fa2e47960fc]
localhost vsep: EMERG: 0: sig_handler(): /lib64/libglib-2.0.so.0(+0x6d745) [0x7fa2e4795745]
localhost vsep: EMERG: 0: sig_handler(): /lib64/libpthread.so.0(+0x7df3) [0x7fa2e4109df3]
localhost vsep: EMERG: 0: sig_handler(): /lib64/libc.so.6(clone+0x6d) [0x7fa2e3e373dd]
localhost vsep: EMERG: 0: sig_handler(): Unmarking all fanotify marked mount points