2020年7月1日 (初版)
2020年8月6日 (アップデート)
| TAC SR Collection |
| 主な問題 |
ESXi6.7.x において、TeamPolicyUpDelay の値を変更しても値を反映した動作となりません。
# esxcli system settings advanced set -o /Net/TeamPolicyUpDelay --int-value 30000 (変更)
# esxcli system settings advanced list -o /Net/TeamPolicyUpDelay (確認)
Path: /Net/TeamPolicyUpDelay
Type: integer
Int Value: 30000 <<<<<<<<<<<< 設定上は反映される
Default Int Value: 100
Min Value: 0
Max Value: 600000
String Value:
Default String Value:
Valid Characters:
Description: Delay (ms) before considering an `uplink up' event relevant
# netdbg vswitch runtime get
AllowFastPath: 0
snip...
TeamPolicyUpDelay: 100 <<<<<<<<<<<<<<<<<<<<<<< 実際は、100 ms に沿った動作となる
|
| 原因 |
TeamPolicyUpDelay は、ESXi がパスの復旧を検知してから実際にパケットをそのパスを使用して送受信するまでの意図的なdelay (単位は ms)となります。 この値が十分ではないと、以下の記事で紹介しておりますように、パスの切り替えのタイミングでクラスタダウンが発生する可能性があります。
VMware 社の原因調査の結果、ESXi 6.7 において、上記記事で紹介しております変更方法で値を変更しても、実際の動作に反映されない不具合が確認されました。
|
| 解決策 |
ワークアラウンドとして、各ESXi ホスト の ESXi shell にて以下のコマンドを実行してください。
# netdbg vswitch runtime set TeamPolicyUpDelay 30000
しかしながら、これにより変更した値は ESXi 再起後にデフォルト値に戻ってしまいますので、ユーザによる再起動や再起動を伴うメンテナンス作業などを実施後は、都度、上記コマンドを実行下さい。
設定後、"netdbg vswitch runtime get" コマンドにて確認してください。
# netdbg vswitch runtime get
AllowFastPath: 0
(省略)
TeamPolicyUpDelay: 30000
|
備考
本不具合は、Bug Search Tool でも確認できます。
各製品の TAC SR Collection の一覧は、よくある質問と解決方法 (TAC SR Collection) から確認できます。
