いずれかの DFW ルールで「適用先」が構成されている場合(「適用先」が「DFW」に設定されていない場合)は、この手順を使用します。

注: NSX-V から NSX への移行については、ナレッジベースの記事 https://kb.vmware.com/s/article/56991を参照してください。

NSXNSX-V に移行する場合、NSX-V の分散ファイアウォール フィルタが NSX よりも常に高いため、ワークロード仮想マシンを NSX-V に戻すと機能しないことがあります。回避策として、vMotion の前にワークロード仮想マシンを NSX 除外リストに配置します。

前提条件

  • 次のように設定されていることを確認します。
    • この移行に関係するクラスタ内の各ホストの VMkernel アダプタで、vSphere vMotion が有効になっている。VMkernel アダプタで vMotion を有効にする手順の詳細については、vSphere の製品ドキュメントを参照してください。
    • NSX の宛先ホストに仮想マシンの移行に十分なリソースが用意されている。
    • 移行元と移行先のホストが動作状態になっている。切断状態など、ホストに関するすべての問題を解決します。

vMotion の詳細については、vSphere 製品ドキュメントのvMotion での移行を参照してください。

手順

  1. スクリプトを実行して、仮想マシン内の各 vNIC に外部 ID を指定し、仮想マシンを正しい論理ポートに vMotion します。
    論理ポートはすでに Migration Coordinator によって作成されています。以下のサンプル コード(および github のスクリプト)は、vNIC が作成された論理ポートに接続できるように、各 vNIC の external-id を決定します。
    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を参照してください。

  2. 移行した仮想マシンにセキュリティ タグと仮想マシンの静的メンバーシップを適用します。
    POST https://{nsxt-mgr-ip}/api/v1/migration/vmgroup?action=post_migrate
    post_migrate アクションが設定された vmgroup API エンドポイントにより、 NSX オーバーレイセグメント上の移行されたワークロード仮想マシンに NSX-V セキュリティ タグが適用されます。

    この API の要求本文の例については、NSX Tech Zone の記事の Lift and Shift Migration Process セクションを参照してください。

  3. インフラストラクチャをファイナライズして、移行を完了します。
    POST https://{nsxt-mgr-ip}/api/v1/migration?action=finalize_infra
    この移行 API では、移行中に作成された一時的なオブジェクト構成が削除され、 NSX インフラストラクチャがクリーンな状態になります。たとえば、一時的な IP セットがグループから削除されます。

    この POST API には要求の本文がありません。

  4. 必要なすべての構成アイテムが NSX 環境に移行されていることを確認します。
    たとえば、次の構成が正常に移行されたかどうかを確認します。
    • ユーザー定義の分散ファイアウォール ルール。
    • IP セット、グループ、タグなどのグループ化されたすべてのオブジェクト。
    • 動的グループに有効なメンバーが表示されます。
    • タグは、移行されたワークロード仮想マシンに適用されます。
  5. (オプション) NSX 4.1.1 以降では、移行が完了し、[終了] をクリックする前に [移行レポートの取得] をクリックすると、特定のオブジェクトが正しく移行されたかどうかを確認できます。レポートの準備ができたら、[レポートをダウンロード] をクリックします。
    レポートには、次の情報が含まれます。
    • NSX-V および移行後にセキュリティ タグを持つ仮想マシン。違いがある場合は、リストに表示されます。
    • NSX-V および移行後のセキュリティ グループ。違いがある場合は、リストに表示されます。
  6. [ワークロードの移行] ページで [終了] をクリックします。
    移行の終了を確認するダイアログ ボックスが表示されます。移行が終了すると、すべての移行の詳細は消去されます。終了した移行の設定を確認することはできなくなります。たとえば、 [構成の解決] ページで行った入力など。

次のタスク

ワークロード仮想マシンと DFW のみの構成が正常に移行され、完全に検証されたら、レイヤー 2 ブリッジを削除して、ブリッジに使用した NSX Edge を解放します。