Edge Services Gateway を正常に移行したら、NSX-V ホストを NSX-T ホスト トランスポート ノードに移行できます。

前提条件

  • Edge の移行が終了し、すべてのルーティングおよびサービスが正しく動作していることを確認します。
  • vCenter Server のユーザー インターフェイスで、[ホストおよびクラスタ] ページに移動し、すべての ESXi ホストが動作状態になっていることを確認します。切断状態を含む、ホストに関するすべての問題を解決します。メンテナンス モードを開始および終了するには、保留中の再起動または保留中のタスクがないことを確認してください。

手順

  1. [ホストの移行] ページで [開始] をクリックします。
  2. 任意のホスト グループの移行モードに [手動メンテナンス] を選択した場合、メンテナンス モードに切り替えられるように、各仮想マシンで以下のいずれかのタスクを完了する必要があります。
    オプション アクション
    一時停止している仮想マシンをパワーオフします。
    1. 仮想マシンを右クリックします。[電源] > [パワーオフ] の順に選択するか、[電源] > [ゲスト OS をシャットダウン] の順に選択するか、[電源] > [一時停止] の順に選択します。
    2. ホストの移行後、仮想マシンのインターフェイスを適切な NSX-T セグメントに接続し、仮想マシンをパワーオンします。
    vMotion を使用して仮想マシンを移動します。 仮想マシンを右クリックして、[移行] を選択します。プロンプトに従って、仮想マシンを別のホストに移行します。Migration Coordinator は、一時ルールで保護されている特定のポートに仮想マシンを vMotion することで、移行中のセキュリティを維持します。手動 vMotion の場合は、これらのポートに仮想マシンが移行されないため、セキュリティ侵害が発生する可能性があります。手動で vMotion を実行するには、vSphere API を使用して、仮想マシンを移行する必要があります。その場合、ネットワーク バッキングが NSX セグメント（NVDS を使用する場合）または VDS ポートグループ ID（VDS 7 を使用する場合）に対応する OpaqueNetwork ID を参照している必要があります。いずれの場合も、ネットワーク デバイスの externalId は文字列「VM_UUID:vNIC_ID」に設定する必要があります。VM_UUID は、仮想マシンのインスタンス UUID です。vNIC_ID は仮想マシンの vNIC インデックスで、最初の vNIC は 4000 です。
    コールド移行で仮想マシンを移動します。
    1. 仮想マシンを右クリックします。[電源] > [パワーオフ] の順に選択するか、[電源] > [ゲスト OS をシャットダウン] の順に選択するか、[電源] > [一時停止] の順に選択します。
    2. 仮想マシンを右クリックして、[移行] を選択します。プロンプトに従って、仮想マシンを別のホストに移動し、そのインターフェイスを適切な NSX-T セグメントに接続します。
    次の Python コードでは、vNIC が正しいポートで ID 「ls_id」の NSX-T セグメントに接続するように、仮想マシン内の各 vNIC の外部 ID を指定して、仮想マシンの vMotion を行っています。 
    devices = vmObject.config.hardware.device
nic_devices = [device for device in devices if isinstance(device, vim.Vm.device.VirtualEthernetCard)]
vnic_changes = []
for device in nic_devices:
    vif_id = vmObject.config.instanceUuid + ":" + str(device.key)
    vnic_spec = self._get_nsxt_vnic_spec(device, ls_id, vif_id)
    vnic_changes.append(vnic_spec)
relocate_spec = vim.Vm.RelocateSpec()
relocate_spec.SetDeviceChange(vnic_changes)
# set other fields in the relocate_spec
vmotion_task = vmObject.Relocate(relocate_spec)
WaitForTask(vmotion_task)

def _get_nsxt_vnic_spec(self, device, ls_id, vif_id):
    nsxt_backing = vim.Vm.Device.VirtualEthernetCard.OpaqueNetworkBackingInfo()
    nsxt_backing.SetOpaqueNetworkId(ls_id)
    nsxt_backing.SetOpaqueNetworkType('nsx.LogicalSwitch')
    device.SetBacking(nsxt_backing)
    device.SetExternalId(vif_id)
    dev_spec = vim.Vm.Device.VirtualDeviceSpec()
    dev_spec.SetOperation(vim.Vm.Device.VirtualDeviceSpec.Operation.edit)
    dev_spec.SetDevice(device)
    return dev_spec

    完全なスクリプトの例については、https://github.com/dixonly/samples/blob/main/vmotion.pyを参照してください。

    すべての仮想マシンが移動済み、パワーオフ、または一時停止状態になると、ホストがメンテナンス モードに切り替わります。コールド移行を使用して、移行中のホストがメンテナンス モードに入る前に、仮想マシンを別のホストに移動する場合は、仮想マシンの移動中に少なくとも 1 台の仮想マシンが実行されている必要があります。最後の仮想マシンンがパワーオフするか、一時停止になると、ホストはメンテナンス モードに切り替わり、 NSX-T へのホストの移行が開始します。

結果

移行モードに [インプレース] を選択して NSX-T にホストを移行すると、重大アラームが表示され、「ネットワーク接続が失われました」というメッセージが表示されることがあります。このアラームは、以前に接続されていた VDS に接続されている物理 NIC がホストにないため、vSphere Distributed Switch (VDS) 6.5 または 6.7 が、N-VDS に移行された場合に発生します。移行したホストを接続状態に戻すには、各ホストで [緑にリセット] をクリックして、警告が表示されないようにします。

1 台のホストで移行に失敗した場合、そのホスト グループをグループ リストの最後に移動できます。これにより、失敗したホストの問題を解決している間に、他のホスト グループの移行を続けることができます。

1 台のホストで移行に失敗すると、実行中のホスト移行がすべて完了した後で、移行が一時停止します。このホストの問題を解決したら、[再試行] をクリックして、失敗したホストの移行を再試行します。ホストの移行にそれでも失敗した場合は、ホストの NSX-T を手動で構成するか、システムからホストを削除できます。この場合、移行に失敗したホストが原因でホストの移行手順の最後に [終了] ボタンが有効になりません。移行を完了して移行後のタスクを実行するには、REST API クライアント（postman や curl など）を使用して REST API POST https://<nsx-mgr-IP>/api/v1/migration?action=finalize_infra（<nsx-mgr-IP> は移行サービスが実行されている NSX Manager の IP アドレス）を呼び出す必要があります。

その他のホスト移行の問題のトラブルシューティングについては、移行の問題のトラブルシューティング を参照してください。

次のタスク

移行後のセキュリティ ポリシーでサードパーティのパートナー サービスを使用している場合は、 NSX-T にパートナー サービスのインスタンスを展開します。詳細な手順については、次を参照してください。