自宅で検証できそうなスペックに合わせたNSX-Tのインストール手順を紹介します。NSX Manager 3台, NSX Edge 2台, ESXi 2台, vCenter 1台の構成で、このページではオーバーレイトランスポートゾーンの設定方法を説明します。
このページでは廉価構成を想定していますので、ベアメタルにESXiをインストールするのではなく、ESXiの中にESXiを構築する「Nested ESXi」と呼ばれる構成の構築例を紹介します。
構築範囲
このページでは、オーバーレイトランスポートゾーンの設定を説明します。構築範囲を図示すると以下の範囲です。
オーバーレイトランスポートゾーンの作成
NSX-Tはトランスポートゾーンと呼ばれる疎通可能な範囲を定義することができます。トランスポートゾーンは「オーバーレイ」と「VLAN」があります。前者の「オーバーレイ」はNSX Edgeやホストトランスポートゾーン間のトンネル間の通信の定義です。
デフォルト設定のオーバーレイトランスポートゾーンを使用しても問題ないですが、このページではオーバーレイトランスポートゾーンを自作する方法を説明します。「システム」「ファブリック」「トランスポートゾーン」「ゾーンの追加」の順に押下します。
トランスポートゾーンの「名前」を入力し、「トラフィックタイプ」は「オーバーレイ」とします。その後、「追加」を押下します。
オーバーレイトランスポートゾーンが追加されたことを確認します。
NSX Edgeの設定
NSX Edge用 アップリンクプロファイルの作成
NSX Edgeはアップリンクに対するMTUや冗長化などの設定を「アップリンク プロファイル」という単位でまとめて管理します。NSX Edge向けのアップリンクプロファイルを作成します。
「システム」「ファブリック」「プロファイル」「アップリンク プロファイル」「プロファイルの追加」の順に押下します。
「名前」に何かわかりやすい名前を入力します。
「アクティブリンク」と「スタンバイリンク」それぞれに名前をつけます。この構成の場合は、vNICを1つしか使わないので「アクティブリンク」のみに名前をつけます。「スタンバイリンク」への命名はしないでください。以下スクリーンショットの場合は、「uplink1」との名前をつけています。
仮想マシンのNSX Edgeを使う場合は、VDS(分散仮想スイッチ)で冗長化設定をすれば「アクティブリンク」のみで冗長化を担保できます。しかし、ベアメタルのNSX Edgeを使う場合は、このアップリンクプロファイルの機能を用いて冗長化を実現しなければなりません。
以上の設定完了後、「追加」を押下します。
設定が追加されたことを確認します。
ホストスイッチの設定
NSX EdgeにTEP(Tunnel End Point)を呼ばれるIPアドレスを付与して、NSX Edgeとホストトランスポートノードの間でgeneveによるトンネルを確立します。
この設定を入れるには、「システム」「ファブリック」「ノード」「Edge トランスポートノード」の順に画面遷移し、対象のNSX Edgeにチェックを入れ「編集」を押下します。
「Edgeスイッチ名」を入力します。何か分かりやすい名前が良いのは当然ですが、あまり他の設定と関係する設定ではないので、それほどこだって名前をつけるほどではないかと思われます。
前述の操作で設定した「（オーバーレイ）トランスポートゾーン」「アップリンクプロファイル」を指定します。
「IP割り当て」を「固定IPのリストを使用」にすると、静的にIPアドレスを割り当てることができます。「IPアドレス」「サブネットマスク」「デフォルトゲートウェイ」を指定します。
最後に、TEPのアップリンクとなるインターフェースを指定します。このシナリオの場合ならば「fp-eth0」になります。
以上の設定完了後、「保存」を押下します。
「TEPアドレス」の列にIPアドレスが記載されたことを確認します。
TEPアドレスへping疎通可能であることを確認します。他のNSX Edgeにも同様の操作をします。
[root@ansible012 ~]# ping 192.168.2.131 PING 192.168.2.131 (192.168.2.131) 56(84) bytes of data. 64 bytes from 192.168.2.131: icmp_seq=1 ttl=63 time=3.59 ms 64 bytes from 192.168.2.131: icmp_seq=2 ttl=63 time=0.507 ms 64 bytes from 192.168.2.131: icmp_seq=3 ttl=63 time=0.579 ms ^C --- 192.168.2.131 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 0.507/1.558/3.590/1.437 ms [root@ansible012 ~]#
ホストトランスポートノードの設定
VDS(分散仮想スイッチ)の作成
NSX-T向け用途として使用するVDS(分散仮想スイッチ)を作成します。VDS(分散仮想スイッチ)の操作は、「分散仮想スイッチ(VDS)の基本操作01」などを参照ください。
vCenterにて、データセンタの右クリックメニューで「Distributed Switch」「新しい Distributed Switch」を選びます。
作成するVDSはポートグループを作らないように注意ください。
分散仮想スイッチの右クリックメニューで「設定」「設定の編集」を選びます。
NSX-Tが使用するVDSはMTUサイズ1600バイト以上が必要です。MTUサイズを変更します。
分散仮想スイッチの右クリックメニューで「ホストの追加と管理」を選びます。
ホストトランスポートノードとして使用するESXiを、この分散仮想スイッチに割り当てます。
ESXi用 アップリンクプロファイルの作成
NSX Edgeはアップリンクに対するMTUや冗長化などの設定を「アップリンク プロファイル」という単位でまとめて管理します。ESXi向けのアップリンクプロファイルを作成します。
「システム」「ファブリック」「プロファイル」「アップリンク プロファイル」「プロファイルの追加」の順に押下します。
「名前」に何かわかりやすい名前を入力します。
「アクティブリンク」と「スタンバイリンク」それぞれに名前をつけます。
NSX Edge向けのプロファイルではVDSがvlanタグを付与するのでvlan0としましたが、ESXiの場合はVDSはvlanタグを付与しないのでアップリンクプロファイルの機能でvlanタグを付与します。このシナリオの場合ならば、「2」を入力します。
vlanタグを付与できる設定は色々あります。VDSでも設定可能ですし、アップリンクプロファイルでも設定可能です。また、物理スイッチでタグの付与が可能です。設定方法は色々ありますが、二重三重でvlanタグを付与しないように注意しましょう。大規模プロジェクトでは、この辺りの設定は異なる担当者が実装するため認識相違が発生しやすいポイントです。
以上の設定完了後、「追加」を押下します。
設定が追加されたことを確認します。
ホストスイッチの設定
ESXi(ホスト トランスポート ノード)にTEP(Tunnel End Point)を呼ばれるIPアドレスを付与して、NSX Edgeとホスト トランスポート ノードの間でgeneveによるトンネルを確立します。
この設定を入れるには、「システム」「ファブリック」「ノード」「ホスト トランスポートノード」「vCenter名」の順に画面遷移し、対象のESXiにチェックを入れ「NSXの設定」を押下します。
「次へ」を押下します。
「タイプ」と「モード」は、デフォルト設定の「VDS」「標準」とします。
「名前」はNSX用途として作成したVDSをプルダウンで選びます。前述の操作で設定した「（オーバーレイ）トランスポートゾーン」「アップリンクプロファイル」を指定します。「アップリンクプロファイル」はESXi向けに作成したvlanタグありのものを指定してください。このシナリオならば、「prof-host-single-01」です。
「IP割り当て」を「固定IPのリストを使用」にすると、静的にIPアドレスを割り当てることができます。「IPアドレス」「サブネットマスク」「デフォルトゲートウェイ」を指定します。
最後に、TEPのアップリンクを指定します。ここで指定するのはVDSに対して設定したアップリンクです。デフォルト設定ならば「アップリンク 1」などの名前になっているでしょう。
以上の設定完了後、「保存」を押下します。
設定が完了するまで待ちます。
「TEPアドレス」の列にIPアドレスが記載されたことを確認します。
TEPアドレスへping疎通可能であることを確認します。他のESXiにも同様の操作をします。
[root@centos221 ~]# ping 192.168.2.141 PING 192.168.2.141 (192.168.2.141) 56(84) bytes of data. 64 bytes from 192.168.2.141: icmp_seq=1 ttl=63 time=0.912 ms 64 bytes from 192.168.2.141: icmp_seq=2 ttl=63 time=1.27 ms 64 bytes from 192.168.2.141: icmp_seq=3 ttl=63 time=1.38 ms 64 bytes from 192.168.2.141: icmp_seq=4 ttl=63 time=1.21 ms 64 bytes from 192.168.2.141: icmp_seq=5 ttl=63 time=1.04 ms ^C --- 192.168.2.141 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 9ms rtt min/avg/max/mdev =
疎通確認
NSX Edgeとホストトランスポートノードの間でトンネルが確立されたことを確認します。
ホストトランスポートノードの「状態」を押下すると、より詳しい状態を見ることができます。「ノードの状態」が「稼働中」と表示されていることを確認します。
「トンネル」が「使用不可」と表示されていますが、これは想定通りで正常な挙動です。ここには確立されたトンネル数が表示されますが、トンネル数が表示されるのは「NSX-T 3.1.2 最小限構成のインストール方法 (6/7)」を完了させた後です。
Edgeトランスポートノードの「状態」を押下すると、より詳しい状態を見ることができます。「ノードの状態」が「稼働中」と表示されていることを確認します。
補足説明
トラブル調査
トンネルの状態
「システム」「ファブリック」「ノード」「ホストトランスポートノード」の順に押下して表示される画面において、「トンネル」が「使用不可」と表示されています。詳細を開くと「トンネルを使用できません」と表示されます。
これは一見するとエラーのように見えますが、実は正常な挙動です。ホストトランスポートノードでトンネルが確立されるのは、NSX-Tで作成されたセグメントに接続された仮想マシンが起動したタイミングです。「NSX-T 3.1.2 最小限構成のインストール方法 (6/7)」が完了した時点でトンネルが確立されないのはホストトランスポートノードの設定誤りですが、現時点で「トンネルを使用できません」と表示されるのは正常な挙動です。
言い方を変えれば、ホストトランスポートノードの設定に誤りがあっても現時点では明確なエラーメッセージは出力されません。「NSX-T 3.1.2 最小限構成のインストール方法 (6/7)」まで操作が完了した時点でトラブルシュートした方が近道です。
仮想マシン起動後は、正常に確立されたトンネルが緑で表示され、異常があったトンネルが赤で表示されます。以下スクリーンショットのように赤で表示されれば、ホストトランスポートノードに設定誤りがあったことを意味します。
仮想マシン起動後に、正常にトンネルが確立されている場合は以下のように表示されます。
ノードの状態
「システム」「ファブリック」「ノード」「Edgeトランスポートノード」の順に押下して表示される画面において、「ノードの状態」が「劣化」または「停止」と表示されるのは、Edgeトランスポートノードへの疎通不能の状態を表します。
ホストトランスポートノードのvmk10からEdgeトランスポートノードへの疎通が可能かどうかを確認しましょう。vmk10のIPアドレスを調べるには、以下のようなesxcliコマンドを使用します。
[root@esxi141:~] esxcli network ip interface ipv4 get Name IPv4 Address IPv4 Netmask IPv4 Broadcast Address Type Gateway DHCP DNS ----- ------------- ------------- --------------- ------------ ----------- -------- vmk0 192.168.1.141 255.255.255.0 192.168.1.255 STATIC 192.168.1.1 false vmk10 192.168.2.141 255.255.255.0 192.168.2.255 STATIC 192.168.2.1 false vmk50 169.254.1.1 255.255.0.0 169.254.255.255 STATIC 192.168.1.1 false
pingコマンドを使った疎通確認例は以下の通りです。
[root@esxi141:~] ping -c 3 192.168.2.131 PING 192.168.2.131 (192.168.2.131): 56 data bytes 64 bytes from 192.168.2.131: icmp_seq=0 ttl=63 time=0.531 ms 64 bytes from 192.168.2.131: icmp_seq=1 ttl=63 time=0.672 ms 64 bytes from 192.168.2.131: icmp_seq=2 ttl=63 time=0.674 ms --- 192.168.2.131 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.531/0.626/0.674 ms [root@esxi141:~] [root@esxi141:~] [root@esxi141:~] ping -c 3 192.168.2.132 PING 192.168.2.132 (192.168.2.132): 56 data bytes 64 bytes from 192.168.2.132: icmp_seq=0 ttl=63 time=3.634 ms 64 bytes from 192.168.2.132: icmp_seq=1 ttl=63 time=0.633 ms 64 bytes from 192.168.2.132: icmp_seq=2 ttl=63 time=0.723 ms --- 192.168.2.132 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.633/1.663/3.634 ms [root@esxi141:~] [root@esxi141:~] [root@esxi141:~] ping -c 3 192.168.2.133 PING 192.168.2.133 (192.168.2.133): 56 data bytes --- 192.168.2.133 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss
vmkpingコマンドを使った疎通確認例は以下の通りです。vmkpingは-Sでプロトコルスタックを指定するなどの若干の慣れを必要とします。慣れないうちはping応答がなかったとしても、コマンドのオプション指定誤りの可能性もあることに注意しましょう。
[root@esxi141:~] vmkping -I vmk10 -S vxlan 192.168.2.131 PING 192.168.2.131 (192.168.2.131): 56 data bytes 64 bytes from 192.168.2.131: icmp_seq=0 ttl=64 time=0.330 ms 64 bytes from 192.168.2.131: icmp_seq=1 ttl=64 time=0.414 ms 64 bytes from 192.168.2.131: icmp_seq=2 ttl=64 time=0.435 ms --- 192.168.2.131 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.330/0.393/0.435 ms [root@esxi141:~] [root@esxi141:~] [root@esxi141:~] vmkping -I vmk10 -S vxlan 192.168.2.132 PING 192.168.2.132 (192.168.2.132): 56 data bytes 64 bytes from 192.168.2.132: icmp_seq=0 ttl=64 time=3.026 ms 64 bytes from 192.168.2.132: icmp_seq=1 ttl=64 time=0.345 ms 64 bytes from 192.168.2.132: icmp_seq=2 ttl=64 time=0.336 ms --- 192.168.2.132 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.336/1.236/3.026 ms [root@esxi141:~] [root@esxi141:~] [root@esxi141:~] vmkping -I vmk10 -S vxlan 192.168.2.133 PING 192.168.2.133 (192.168.2.133): 56 data bytes --- 192.168.2.133 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss
Edgeトランスポートノードの修正
設定誤りを発見した場合は、NSX EdgeをOVAテンプレートのデプロイからやりなおす必要はなく、設定の修正のみで十分です。設定誤りがあるEdgeトランスポートノードにチェックを入れ「編集」を押下します。
設定誤りの部分を修正し「保存」を押下します。
自動化
オーバーレイトランスポートゾーン
オーバーレイトランスポートゾーンを設定するRest API操作は以下の通りです。
curl --request POST -d @- \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/transport-zones << EOF
{
"display_name":"tz-overlay-01",
"host_switch_name":"host-switch-tz-overlay01",
"transport_type":"OVERLAY"
}
EOF
アップリンクプロファイル
アップリンクプロファイル（APIドキュメントでは「HostSwitchProfile」との表記）を登録するRest API操作は以下の通りです。
curl --request POST -d @- \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/host-switch-profiles << EOF
{
"resource_type" : "UplinkHostSwitchProfile",
"display_name" : "prof-edge-single-01",
"teaming": {
"policy" : "FAILOVER_ORDER",
"active_list" : [ {
"uplink_name" : "uplink1",
"uplink_type" : "PNIC"
}
]
},
"transport_vlan": 0
}
EOF
curl --request POST -d @- \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/host-switch-profiles << EOF
{
"resource_type" : "UplinkHostSwitchProfile",
"display_name" : "prof-host-redundant-01",
"teaming" : {
"policy" : "FAILOVER_ORDER",
"active_list" : [ {
"uplink_name" : "uplink1",
"uplink_type" : "PNIC"
} ],
"standby_list" : [ {
"uplink_name" : "uplink2",
"uplink_type" : "PNIC"
} ]
},
"transport_vlan": 2
}
EOF
ホストスイッチ作成(Edge)
NSX Edge ホストスイッチを作成するAPI操作例です。NSX Edge ホストエッジはEdgeトランスポートノードのデータの一部として管理されているデータ構造なので、Edgeトランスポートノードを「追加」するのではなく「更新」します。よって、POSTリクエストではなくPUTリクエストを送信してください。また、「アップリンクプロファイル」や「トランスポートゾーン」は名前ではなくIDで指定しなければならないので、適宜、IDを検索するような操作が必要になります。
NODE_DISPLAY_NAME="nsx-edge132.gokatei.go"
NODE_IP_ADDRESS="192.168.2.132"
NODE_SUBNET_MASK="255.255.255.0"
NODE_DEFAUT_GATEWAY="192.168.2.1"
UPLINK_PROF_DISPLAY_NAME="prof-edge-single-01"
TZ_DISPLAY_NAME="tz-overlay-01"
WORK_FILE=/tmp/nsx_api_work_$$
curl --request GET \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/transport-nodes \
| jq --arg arg ${NODE_DISPLAY_NAME} ' .results[] | select ( .display_name == $arg ) ' \
> ${WORK_FILE}
NODE_ID=$(cat ${WORK_FILE} | jq -r ".node_id")
REVISION=$(cat ${WORK_FILE} | jq -r "._revision")
rm -f WORK_FILE
TZ_ID=$(curl --request GET \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/transport-zones \
| jq -r --arg arg ${TZ_DISPLAY_NAME} ' .results[] | select ( .display_name == $arg ) | .id ' )
UPLINK_PROF_ID=$(curl --silent --request GET \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/host-switch-profiles \
| jq -r --arg arg ${UPLINK_PROF_DISPLAY_NAME} ' .results[] | select ( .display_name == $arg ) | .id')
curl --request PUT -d @- \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/transport-nodes/${NODE_ID} << EOF
{
"host_switch_spec" : {
"host_switches" : [ {
"host_switch_name" : "nsxHostSwitchOverlay",
"host_switch_type" : "NVDS",
"host_switch_mode" : "STANDARD",
"host_switch_profile_ids" : [ {
"key" : "UplinkHostSwitchProfile",
"value" : "${UPLINK_PROF_ID}"
} ],
"pnics" : [ {
"device_name" : "fp-eth0",
"uplink_name" : "uplink1"
} ],
"is_migrate_pnics" : false,
"ip_assignment_spec" : {
"ip_list" : [ "${NODE_IP_ADDRESS}" ],
"default_gateway" : "${NODE_DEFAUT_GATEWAY}",
"subnet_mask" : "${NODE_SUBNET_MASK}",
"resource_type" : "StaticIpListSpec"
},
"transport_zone_endpoints" : [ {
"transport_zone_id" : "${TZ_ID}"
} ]
} ],
"resource_type" : "StandardHostSwitchSpec"
},
"display_name" : "${NODE_DISPLAY_NAME}",
"description" : "",
"_revision": ${REVISION}
}
EOF
ホストスイッチ作成(ESXi)
GUI操作ではワンボタンで操作していますが、APIではPOSTリクエストでホストスイッチの設定を作成した後に、vCenterとのデータ連携が完了するのを待ってからVDSと関連する設定をPUTリクエストで変更します。一定時間待ってからの操作でないと、連携部分の設定でエラーが返されます。
自動化する場合は、一定時間待った後のエラーハンドル付きの繰り返し実行が必要になります。
POSTリクエストでホストスイッチを作成する実装例は以下の通りです。ホストスイッチ作成時にESXiにVIBをインストールするため、ESXiに対する認証情報が必要になります。ですので、POSTリクエストに含まれるユーザ名とパスワードはESXiの認証情報を指定してください。
NODE_DISPLAY_NAME="192.168.1.142"
NODE_IP_ADDRESS="192.168.2.142"
NODE_SUBNET_MASK="255.255.255.0"
NODE_DEFAUT_GATEWAY="192.168.2.1"
UPLINK_PROF_DISPLAY_NAME="prof-host-redundant-01"
TZ_DISPLAY_NAME="tz-overlay-01"
VCENTER_DISPLAY_NAME="vcenter01"
HOST_SWITCH_NAME="DSwitch1",
WORK_FILE=/tmp/nsx_api_work_$$
TZ_ID=$(curl --request GET \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/transport-zones \
| jq -r --arg arg ${TZ_DISPLAY_NAME} ' .results[] | select ( .display_name == $arg ) | .id ' )
UPLINK_PROF_ID=$(curl --silent --request GET \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/host-switch-profiles \
| jq -r --arg arg ${UPLINK_PROF_DISPLAY_NAME} ' .results[] | select ( .display_name == $arg ) | .id')
VCENTER_ID=$(curl --request GET \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/fabric/compute-managers \
| jq -r --arg arg ${VCENTER_DISPLAY_NAME} ' .results[] | select ( .display_name == $arg ) | .id ')
curl --request POST -d @- \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/transport-nodes << EOF > ${WORK_FILE}
{
"node_deployment_info" : {
"os_type" : "ESXI",
"os_version" : "",
"managed_by_server" : "${VCENTER_ID}",
"resource_type" : "HostNode",
"display_name" : "${NODE_DISPLAY_NAME}",
"fqdn" : "",
"ip_addresses" : [ "${NODE_DISPLAY_NAME}" ],
"host_credential": {
"username" : "root",
"password" : "P@ssw0rd",
"thumbprint": "dummy_thumb_print"
}
},
"resource_type" : "TransportNode",
"display_name" : "${NODE_DISPLAY_NAME}",
"description" : ""
}
EOF
NODE_THUMB_PRINT=$(cat ${WORK_FILE} | jq -r ".error_data.ValidThumbPrint")
rm -f WORK_FILE
curl --request POST -d @- \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/transport-nodes << EOF > ${WORK_FILE}
{
"node_deployment_info" : {
"os_type" : "ESXI",
"os_version" : "",
"managed_by_server" : "${VCENTER_ID}",
"resource_type" : "HostNode",
"display_name" : "${NODE_DISPLAY_NAME}",
"fqdn" : "",
"ip_addresses" : [ "${NODE_DISPLAY_NAME}" ],
"host_credential": {
"username" : "root",
"password" : "P@ssw0rd",
"thumbprint": "${NODE_THUMB_PRINT}"
}
},
"resource_type" : "TransportNode",
"display_name" : "${NODE_DISPLAY_NAME}",
"description" : ""
}
EOF
PUTリスクエストで、VDSをホストスイッチとして設定します。変数HOST_SWITCH_IDで指定されるIDは、python pyvmomiモジュールで取得可能なvim.DistributedVirtualSwitch.uuidの値を指定します。
公式では記載されていない追跡方法ですが、HOST_SWITCH_IDはVDSをバックアップした時に生成されるファイル内にも含まれています。pythonの環境を作るよりもVDSをバックアップした方が手っ取り早く調査できると思います。
HOST_SWITCH_ID="50 3c 3b 1c 66 9d a7 72-ca 72 36 16 68 9f 8c 9e"
while true
do
curl --request GET \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/transport-nodes \
| jq --arg arg ${NODE_DISPLAY_NAME} ' .results[] | select ( .display_name == $arg ) ' \
> ${WORK_FILE}
NODE_ID=$(cat ${WORK_FILE} | jq -r ".node_id")
REVISION=$(cat ${WORK_FILE} | jq -r "._revision")
rm -f WORK_FILE
curl --fail --request PUT -d @- \
-u admin:P@ssw0rdP@ssw0rd \
--header "Content-Type:application/json" \
-k https://192.168.1.121/api/v1/transport-nodes/${NODE_ID} << EOF
{
"host_switch_spec" : {
"host_switches" : [ {
"host_switch_name": "${HOST_SWITCH_NAME}",
"host_switch_id": "${HOST_SWITCH_ID}",
"host_switch_type" : "VDS",
"host_switch_mode" : "STANDARD",
"host_switch_profile_ids" : [ {
"key" : "UplinkHostSwitchProfile",
"value" : "${UPLINK_PROF_ID}"
} ],
"uplinks": [
{
"vds_lag_name": "lag1",
"uplink_name": "uplink1"
}
],
"ip_assignment_spec" : {
"ip_list" : [ "${NODE_IP_ADDRESS}" ],
"default_gateway" : "${NODE_DEFAUT_GATEWAY}",
"subnet_mask" : "${NODE_SUBNET_MASK}",
"resource_type" : "StaticIpListSpec"
},
"transport_zone_endpoints" : [ {
"transport_zone_id" : "${TZ_ID}"
} ]
} ],
"resource_type" : "StandardHostSwitchSpec"
},
"display_name" : "${NODE_DISPLAY_NAME}",
"description" : "",
"_revision": ${REVISION}
}
EOF
if [ $? -eq 0 ] ; then
break
fi
echo "retry : wait for vcenter connection"
sleep 10
done
