IBM Cloud Docs
VMware NSX-V から NSX-T へのマイグレーションに関する FAQ

VMware NSX-V から NSX-T へのマイグレーションに関する FAQ

Automatedインスタンスを削除すると、ネットワークやストレージ資産はどうなりますか?

VMware Cloud Foundation for Classic - Automated インスタンスを削除すると、ネットワーク (プライベートおよびパブリックのサブネットを持つ VLAN) とストレージ (IBM Cloud® File Storage for Classic) アセットは IBM Cloud ベアメタルサーバと共にキャンセルされます。 移行にネットワークまたはストレージ資産がある場合は、IBM Cloud が VLAN と関連するサブネット、および NFS ストレージを元のインスタンスから切り離すようにサポート チケットを開いてください。 VCF for Classic - Automated インスタンスが削除されても、これらのアセットはキャンセルされません。

以下の推奨事項が適用されます。

  • 削除される既存のVCF for Classic - Automatedインスタンスのアセットの使用を避けるように、マイグレーションを設計してください。
  • 既存の資産が必要な場合は、すべての資産を注意深く記録し、リストアップすること。
  • インスタンスを削除する前にサポートチケットを開いてください。 維持したいアセットをすべてリストアップし、これらのアセットが元のインスタンスから切り離されるようにします。 このプロセスに従わなければ、削除後に資産を復元することはできない。

既存のIBM Cloud File Storage for Classicを新しいAutomatedインスタンスにアタッチできますか?

NFS ストレージを使用している場合は、 NFS ストレージを新しいインスタンスに手動でアタッチし、 cross–vCenter vMotion を実行することで、ストレージ vMotion を必要とせずに済みます。 新しいインスタンスから NFS ストレージへの NFS サブネットを許可する必要があります。

以下の推奨事項が適用されます。

  • ブートストラップの目的で、ストレージ・ホスト名用に新規ホスト上に静的/etc/hostsエントリーを構成します。
  • 新しいホストでスタティック・ルートを構成して、NFS へのトラフィックが NFS サブネットおよびストレージ VLAN を介して駆動されるようにします。
  • 移行後、サポートチケットを開き、 IBM Cloud が NFS ストレージを元のインスタンスから切り離すことを確認する。 そして、元のインスタンスが削除されても、ストレージはキャンセルされない。

新しいAutomatedインスタンスで既存の Active Directory を再利用できますか?

ほとんどのお客様は、 vCenter Server とともにデプロイされる AD/DNS サーバーを使用せず、 vCenter Server と NSX® Manager に追加の ID ソースとして独自のドメインコントローラーを追加しています。

以下の情報を知っていれば、既存の Active Directory™ (AD)コントローラを維持し、継続的に使用することができます:

  • 新規インスタンスは、DNS および IBM 自動化ユーザーの認証に使用する必要がある新規ドメイン・コントローラーをデプロイします。
  • 仮想マシン(VM)を使用している場合、古いインスタンスのドメインコントローラーを新しいインスタンスに移行することができる。 VSI を使用している場合は、古いインスタンスのドメイン・コントローラーを新しいインスタンスで使用できます。 新しいインスタンスが元のインスタンスとは異なるルート・ドメインでデプロイされている場合、ドメイン・コントローラーを ID ソースとして vCenter Server および NSX Manager に追加できます。 したがって、古いインスタンス・ドメインがexample.cloud.localの場合、新しいインスタンスにはexample.cloud2.localという名前を付けることができます。 元の AD は、このドメインの DNS を新しい AD に委任するように構成できます。ユーザーは、既存のuser@example.cloud.local ID を使用してログインし、instance1-vc.example.cloud2.localなどのリソース・ホスト名にアクセスできます。
  • 元の AD が VSI としてデプロイされている場合、IBM サポートが元のインスタンスから VSI を切り離すようにサポート・チケットを開きます。 このアクションは、元のインスタンスが削除されたときにVSIがキャンセルされないことを保証する。
  • どのような場合でも、オリジナルの VCF for Classic - Automated インスタンスを削除する前に、オリジナルのコントローラをバックアップすることをお勧めします。

vMotion と vSphere の暗号化を古いインスタンスと新しいインスタンスの間で使用できますか?

VMware vSphere® 暗号化により、 vSphere 暗号化で保護されたVMに対して、高度なクロス vCenter vMotion。 ソース vCenter を v7.0 以降にアップグレードし、両方の vCenters を同じ鍵管理システム(KMS)に接続し、同じ名前を割り当てる必要があります。 また、各 vCenter Server に同等のストレージ暗号化ポリシーがあることも確認してください。

手動でデプロイされたアセットはどうなりますか。

デプロイ済みアセットを手動でインスタンスに追加した場合は、初期デプロイメント後に、自動化でそれらのアセットが認識されません。 そのため、アセットを新規インスタンスに手動でマイグレーションする必要があります。

IBM Cloud のベアメタルサーバーに VMware のワークロードがあり、 vSphere 6.5 と 6.7 がサポート終了です。 ワークロードに NSX を使用していません。 環境をサポートしたままにするには何を行う必要がありますか? また、どのようなオプションがありますか。

vSphere® 6.x の一般サポートは、2022年10月15日に終了しました。 詳細については、vSphere 6.5 および vSAN 6.5または6.6、および VMware製品ライフサイクル マトリックス

vSphere 6.7 を搭載した IBM Cloud ベアメタルサーバーによるインスタンスは、2022 年 6 月 21 日以降は注文できません。IBM Cloud vSphere 6.5 のすべての更新レベルの注文のサポートは 2021 年 10 月 10 日に終了し、vSphere 6.5 は 2022 年 6 月 21 日以降は注文できません

IBM Cloud vSphere へのアップグレードをお勧めします。 7.x IBM Cloud Classic Infrastructureのベアメタルカタログからサーバーを注文した場合、以下のオプションがあります。

  • ご使用のサーバーとそのハードウェア・オプションが vSphere 7.0 と互換性があるかどうかを確認します。 詳細については、『 Broadcom 互換性ガイド』を参照してください。 あるいは、vCenter を実行している場合は、vCenter をアップグレードし、vSphere Update Manager (VUM) または vSphere Lifecycle Manager をセットアップし、アップグレードのためにハードウェア互換性検査を実行することができます。
  • 新しい IBM Cloud ベアメタル サーバーを vSphere 7.x のベアメタル カタログから IBM Cloudクラシック インフラストラクチャのベアメタル カタログから、または VMware Solutions コンソール、VMware Cloud Foundation for Classic - Flexible オファリングから選択できます。 vSphere ホストと vCenter Server を構成し、ワークロードをマイグレーションします。 ワークロードの移行が完了したら、 vCenter Server から VMware ESXi™ ホストを削除し、 IBM Cloud ポータルから古いサーバーを廃止することができます。

古い VMware vSphere インスタンス、 IBM Cloud ベアメタルサーバー、 vSphere 6.5 または 6.7 を持っていますが、サポートが終了します。 ワークロードに NSX を使用していません。 環境をサポートしたままにするには何をする必要がありますか、またどのようなオプションがありますか。

vSphere 6.x の一般サポートは 2022 年 10 月 15 日に終了しました。 詳細については、vSphere 6.5 および vSAN 6.5または6.6、および VMware製品ライフサイクル マトリックス

vSphere 6.7 を搭載した IBM Cloud ベアメタルサーバーのインスタンスは、2022 年 6 月 21 日以降は注文できません。IBM Cloud VMware vSphere 6.5 は 2021 年 10 月 10 日に終了し、VMware vSphere 6.5 は 2022 年 6 月 21 日以降は注文できません

IBM Cloud vSphere へのアップグレードをお勧めします。 7.x VMware Solutions コンソールからサーバーを注文した場合、次のオプションがあります。

  • ご使用のサーバーとそのハードウェア・オプションが vSphere 7.0 と互換性があるかどうかを確認します。 詳細については、『 Broadcom 互換性ガイド』を参照してください。 あるいは、vCenter Server をアップグレードし、vSphere Update Manager (VUM) または vSphere Lifecycle Manager をセットアップし、アップグレードのためにハードウェア互換性検査を実行することもできます。
  • vSphere 7.x を搭載した新しいIBM Cloud ベア メタル サーバーを、VMware Solutions コンソール、VMware Cloud Foundation for Classic - Flexible オファリングから注文します。 vSphere ホストと vCenter Server を構成し、ワークロードを移行します。 ワークロードの移行が完了したら、 vCenter から ESXi ホストを削除し、 IBM Cloud ポータルから古いサーバを廃止することができます。

私は NSX-V インスタンス付きの古い vCenter Server を持っています。 IBM Cloud Bare Metal Servers vSphere 6.5 または 6.7 で、サポートが終了します。 環境をサポートしたままにするには何をする必要がありますか、またどのようなオプションがありますか。

vSphere 6.x の一般サポートは 2022 年 10 月 15 日に終了しました。 詳細については、vSphere 6.5 および vSAN 6.5または6.6、および VMware製品ライフサイクル マトリックス

さらに、 vSphere 6.5 または 6.7 の古い vCenter Server インスタンスは、通常 NSX-V 6.4 を実行します。 NSX-V 6.4 は2022年1月16日に一般サポートを終了し、2023年1月16日に技術ガイダンスを終了した。 VMware® by BroadcomとIBMは、2025年1月15日までNSX-Vをサポートする独占契約を結んでいます。

IBM Cloud では、vSphere 7.x および NSX-T™ 3.x 以降へのアップグレードを推奨しています。

NSX-V から NSX-T への移行( V2T 移行とも呼ばれる)には、 IBM Cloud、 _リフト・アンド・シフトと_呼ばれる移行手法を使用する。リフト・アンド・シフト・アプローチでは、 IBM Cloud オートメーションを使って、新しい VCF for Classic - Automated インスタンスをデプロイする。 NSX-V から NSX-T へネットワーク構成を移行し、インスタンス間でワークロードを移行する必要があります。IBM Cloud は、IBM Cloud for VMware Solutions インスタンスを持つ既存の VCF for Classic - Automated カスタマ向けの検証済みのアプローチとガイダンスのための広範なドキュメントを提供します

私の IBM Cloud ベアメタル・サーバ・ハードウェアが、 vSphere 7.x のインプレース・アップグレードに適しているかどうかを知るにはどうすればよいですか?

ご使用のサーバーとそのハードウェア・オプションが vSphere 7.x と互換性があるかどうかを確認できます。 詳細については、『 Broadcom 互換性ガイド』を参照してください。

あるいは、vCenter をアップグレードし、vSphere Update Manager (VUM) または vSphere Lifecycle Manager をセットアップし、アップグレードのためにハードウェア互換性チェックを実行することもできます。

IBM Cloud の VMware ワークロードに IBM Cloud ベアメタルサーバーを使用するには、どのような方法がありますか?

IBM Cloud で VMware® プラットフォームを使用するには、以下の方法があります。

  • ベアメタル - IBM Cloud Classic Infrastructure のベアメタルカタログを使用し、 vSphere をオペレーティングシステムとするベアメタルサーバーを注文します。 詳しくは、VMware for Classic を参照してください。
  • VCF for Classic - Flexible- VMware Solutions コンソールを使用して、IBM がホストする VMware ホストをプロビジョニングします。 詳細は VCF for Classic - Flexible 概要 を参照。
  • VCF for Classic - Automated- VMware Solutions コンソールを使用して、 vSphere, NSX ベースの IBM- ホスト型プライベート・クラウドをプロビジョニングし、オプションで vSAN。 詳細は、VCF for Classic - Automated 概要 を参照してください。

アップグレード・プロセスとマイグレーション・プロセスは、使用量モデルによって異なります。

IBM Cloud のベアメタルホストで vSphere 6.x をアップグレードしなかった場合、どのような影響がありますか?

vSphere ソフトウェアのアップグレードはお客様の責任であり、サポートされるバージョンにアップグレードするかどうかはお客様が決定します。 しかし、 VMware by Broadcom には、セキュリティアップデートやバグ修正などの製品パッチやアップデートを提供する義務はないため、お客様のビジネスが危険にさらされる可能性があります。 IBM Cloud がお客様の vSphere ライセンスを提供する場合、お客様がアップグレードするまで、 IBM サポートは vSphere 問題についてサポートできません。

VMwareワークロードをIBM Cloudで実行するさまざまな方法 も参照。

古い VMware vSphere のホストで vSphere 6.x をアップグレードしなかった場合、どのような影響がありますか?

vSphere ソフトウェアのアップグレードはお客様の責任であり、サポートされるバージョンにアップグレードするかどうかはお客様が決定します。 しかし、 VMware by Broadcom には、セキュリティアップデートやバグ修正などの製品パッチやアップデートを提供する義務はないため、お客様のビジネスが危険にさらされる可能性があります。 IBM Cloud がお客様の vSphere ライセンスを提供する場合、お客様がアップグレードするまで、 IBM サポートは vSphere 問題についてサポートできません。

VMwareワークロードをIBM Cloudで実行するさまざまな方法 も参照。

古いインスタンス・ホストの vSphere 6.x をアップグレードしなかった場合、どのような影響がありますか?

vSphere ソフトウェアのアップグレードはお客様の責任であり、サポートされるバージョンにアップグレードするかどうかはお客様が決定します。 ただし、 VMware by Broadcom には、セキュリティ アップデートやバグ修正などの製品パッチやアップデートを提供する義務がないため、ビジネスが危険にさらされる可能性があります。 IBM Cloud vSphere 6.xのすべてのアップデートレベルの注文に対するサポートは2021年10月10日に終了し、 vSphere 6.xで新しいインスタンスを注文することはできません。

IBM Cloud では、7.x へのアップグレードを推奨しています。 古いインスタンスで NSX-V を実行している場合は、VCF for Classic - Automated への移行を検討してください。 このリフトおよびシフト・アップグレードのアプローチは、NSX-V のサポートが終了したため、より有益になる可能性があります。 ハードウェアが更新され、 VMware ソフトウェアがアップグレードされ、NSX-T が導入され、インプレース・アップグレードよりもリフト&シフトの移行が少ないターゲット・プラットフォームから利益を得られるかもしれない。

VMwareワークロードをIBM Cloudで実行するさまざまな方法 も参照。

IBM Cloud のベアメタルホストで BYOL を使用している場合、アップグレードにどのような影響がありますか?

vSphere ソフトウェアのアップグレードはお客様の責任で行っていただきます。 ただし、BYOL (Bring Your Own License) では、ライセンス契約を使用して Broadcom サポートによる VMware に直接アクセスできます。IBM Cloud では、IBM Cloud 上のベアメタル サーバー インフラストラクチャのサポートを提供しています。

アップグレードの詳細については 、「ESXi ホストのアップグレードプロセスの概要」 および vSphereの概要」 を参照してください。 アップグレード計画の一環として VCF for Classic - Automated への移行を検討してください。このリフトアンドシフト方式のアップグレードアプローチの方が有益かもしれません。

VMwareワークロードをIBM Cloudで実行するさまざまな方法 も参照。

古い vCenter Server ホストで BYOL を使用している場合、アップグレードにどのような影響がありますか?

vSphere ソフトウェアのアップグレードはお客様の責任で行っていただきます。 しかし、BYOL (Bring Your Own License) では、ライセンス契約を使用して Broadcom サポートによる VMware に直接アクセスできます。IBM Cloud は、IBM Cloud 上のベアメタルサーバーインフラストラクチャのサポートを提供します。 詳しくは、vCenter Server vSphere ソフトウェアの vSphere 6.5 または 6.7 から 7.0 へのアップグレードを参照してください。 古い vCenter Server インスタンスで NSX-V を実行している場合は、VCF for Classic - Automated への移行を検討してください。 このリフト・アンド・シフト・アップグレードのアプローチは、NSX-V のサポート終了により、より有益である可能性があります。

VMwareワークロードをIBM Cloudで実行するさまざまな方法 も参照。

自動化インスタンスで実行されている製品は何ですか?

VCF for Classic - Automated インスタンスでは、 VMware Solutions のユーザー・インターフェイスに以下の情報が表示されます。

  • VMware NSX ネットワーキング ソリューション - NSX
  • NSX for vSphere- 4.1.0.2
  • NSX ライセンス・エディション - VMware NSX Advanced

このインスタンスはNSXバージョン4.1.0.2を実行しています。 IBM Cloud と VMware by Broadcom との間のライセンス契約により、NSX-V ライセンスが NSX-T インスタンスに使用されていた。 新しい VCF for Classic - Automated インスタンスは NSX-T ライセンスを使用するため、インスタンスは正しくライセンスされています。

NSX-T インスタンスを持つ古い vCenter Server で、vSphere 6.7 のインプレース vSphere アップグレードを行うことはできますか?

はい。しかし、新しい VCF for Classic - Automated インスタンスをデプロイして、リフト アンド シフト マイグレーション アプローチを使用することを強くお勧めします。 インプレース vSphere アップグレードの詳細については、アップグレード vCenter Server vSphere ソフトウェアの vSphere 6.5または6.7から7.0 への変更と、重要な考慮事項 について説明します。

また、以下の重要な検討事項を確認する:

  • ドキュメント化されたプロセスが終了すると、VCF for Classic - Automated インスタンスは vSphere 7.0 Update 1c と N-VDS 分散スイッチを実行しています。 この構成は現在サポートされている 自動化インスタンスのためのソフトウェア部品表 とは異なり、vSphere 7.0 Update 3c with Distributed vSwitch 7.0.0 となります。
  • vSphere 7.0 以降および NSX-T Data Center 3.0 以降の N-VDS から VDS スイッチへの移行の詳細については、ホスト スイッチから vSphere 分散スイッチへの移行を参照してください。 現在、この手順は VMware Solutions vCenter Server インスタンスでは検証されていません。
  • IBM Cloudは、N-VDSからVDSへの変換と、このインプレースアップグレードを可能にするためのオートメーションデータベースへの必要な変更の評価を行っています。
  • 現在、ホストの追加やクラスタの追加などの Day 2 自動化ワークフローは、vSphere 6.7 から 7 にアップグレードされ、N-VDS 分散スイッチを使用している古い vCenter Server インスタンスに対してはテストされていません。 顧客は、この自動化が失敗する可能性があること、そしてこの自動化が必要な場合はリフト・アンド・シフト移行方式を使用することを想定しなければならない。 この自動化が不要な場合は、文書化されているアップグレードプロセスを使用できます。
  • ノードとクラスタを追加する機能の回避策は、VCF for Classic - Flexible オファリングを使用することです。 詳細は VCF for Classic - Flexible 概要 を参照。 自動化された配備の後、いくつかの手動タスクを完了する必要があります。
  • アドオン サービスの回避策として、ドキュメント化されたリファレンス アーキテクチャを使用して手動で展開する方法があります。VMware Solutions の「クラシックのソリューション アーキテクチャ」と「ソリューション ガイド」のセクションを参照してください。

NSX-V インスタンスのある古い vCenter Server 用にデプロイされたポータブル サブネットを再利用できますか?

古い vCenter Server® インスタンスを削除すると、IBM Cloud ベアメタルサーバとともにネットワーク (プライベートおよびパブリックのサブネットを持つ VLAN) がキャンセルされます。 移行にネットワーク資産がある場合は、IBM サポートが元のインスタンスから VLAN と関連するサブネットを切り離すようにサポート チケットを開いてください。 そして、インスタンスが削除されても、これらのアセットはキャンセルされない。

以下の推奨事項が適用されます。

  • 削除する既存の vCenter Server インスタンスのアセットを使用しないように移行を設計します。
  • 既存の資産が必要な場合は、すべての資産を注意深く記録し、リストアップすること。
  • インスタンスを削除する前にサポートチケットを開いてください。 維持したいアセットをすべてリストアップし、これらのアセットが元のインスタンスから切り離されるようにします。 このプロセスに従わなければ、削除後に資産を復元することはできない。

しかし、重複するIPアドレスの課題がある場合は、以下のガイダンスに注意してください:

  • 既存のインスタンス管理サブネットに利用可能なIPアドレスがあり、自分用のIPアドレスを使用していない場合は、引き続き使用できます。 新しいインスタンスは、新しいインスタンス管理サブネットから vCenter Server、NSX-T マネージャ、および Active Directory サーバ (AD サーバが VMware VM 上で実行されている場合) の新しい IP アドレスを使用します。 これらのコンポーネントでは、既存のVCSを削除するまで、既存の管理サブネットを再利用することはできません。
  • さらに、NSX-T T0 ゲートウェイは、顧客のワークロード エッジ用に、ポータブル プライベート サブネットおよびポータブル パブリック サブネットから新しい IP アドレスでプロビジョニングされます。 NSX-T T0 ゲートウェイは、アップリンクでセカンダリ IP アドレスをサポートしません。
  • NSX-T T0 ゲートウェイ アップリンク用に既存のサブネットを手動で構成できますが、T0 に構成できるサブネットは 1 つだけです。
  • アップリンクでセカンダリIPサブネットを使用している場合は、トポロジーを再設計する必要があります。 たとえば、新しい静的サブネット を注文し、これらのサブネットを NSX-T T0 HA VIP にルーティングできます。 これらのIPサブネットとアドレスは、NSX-TのNATルール、ロードバランシング、またはオーバーレイ接続されたVMで使用できます。

VMware Solutions コンソールの外部で注文された既存のポータブル サブネットを再利用できますか?

VMware Solutions コンソールの外部にプライベートまたはパブリックのポータブル サブネットを注文し、VMware クラスター上で実行することでワークロードにこれらのサブネットを使用している場合でも、新しいインスタンスが既存の NSX-V ベースのソリューションと同じ VLAN にデプロイされていれば、これらの IP アドレスを引き続き使用できます。

これらの IP アドレスを ESG で NAT ルールやその他のサービスに使用する場合、NSX-T T0 ゲートウェイはアップリンクでセカンダリ IP アドレスをサポートしないことに注意してください。 新しいインスタンスの NSX-T T0 ゲートウェイには、顧客のワークロード エッジ用に、ポータブル プライベート サブネットとポータブル パブリック サブネットから新しい IP アドレスがプロビジョニングされます。 NSX-T T0 ゲートウェイ アップリンク用に既存のサブネットを手動で構成できますが、T0 に構成できるサブネットは 1 つだけです。 アップリンクでセカンダリIPサブネットを使用している場合は、トポロジーを再設計する必要があります。 たとえば、新しい静的サブネット を注文し、これらのサブネットを NSX-T T0 HA VIP にルーティングできます。 これらのIPサブネットとアドレスは、NSX-TのNATルール、ロードバランシング、またはオーバーレイ接続されたVMで使用できます。