IBM Cloud Docs
FAQ about VMware NSX-V to NSX-T migration

FAQ about VMware NSX-V to NSX-T migration

What happens to the networking or storage assets when I delete a vCenter Server instance?

When you delete a VMware vCenter Server® instance, the networking (VLANs with private and public subnets) and storage (IBM Cloud® File Storage for Classic) assets are cancelled together with the IBM Cloud bare metal Servers. If you have networking or storage assets in your migration, open a support ticket to ensure that IBM Cloud decouples the VLANs and related subnets and NFS storage from the original instance. Then, these assets are not cancelled when the vCenter Server instance is deleted.

The following recommendations apply:

  • Design your migration so that you avoid the use of assets from the existing vCenter Server instance, which is to be deleted.
  • If you need any existing assets, note and list all assets carefully.
  • Open the support ticket before you delete the instance. List all assets that you want to maintain to ensure that these assets are decoupled from the original instance. If this process is not followed, the assets cannot be recovered after deletion.

Can I attach my existing IBM Cloud File Storage for Classic to the new vCenter Server instance?

If you are using NFS storage, you can manually attach the NFS storage to the new instance and perform a cross–vCenter vMotion without requiring a storage vMotion. You must authorize the NFS subnet from their new instance to the NFS storage.

The following recommendations apply:

  • Configure static /etc/hosts entries on the new hosts for the storage hostnames for bootstrap purposes.
  • Configure static routes on the new hosts to ensure that traffic to the NFS is driven over the NFS subnet and storage VLAN.
  • After migration, open a support ticket to ensure that IBM Cloud decouples the NFS storage from the original instance. Then, the storage is not cancelled when the original instance is deleted.

Can I reuse my existing Active Directory in the new vCenter Server instance?

Most customers do not use the AD/DNS servers that are deployed with vCenter Server, but instead added their own domain controllers as an extra identity source to vCenter Server and NSX® Manager.

You can preserve the existing Active Directory™ (AD) controllers for ongoing use if you are aware of the following information:

  • The new instance deploys new domain controllers that it must use for DNS and authenticating the IBM automation users.
  • If you are using virtual machines (VMs), the domain controllers from the old instance can be migrated to the new instance. If you are using VSIs, the domain controllers from the old instance can be used by the new instance. If the new instance is deployed with a different root domain than the original instance, the domain controllers can be added as an identity source to vCenter Server and NSX Manager. So, if the old instance domain is example.cloud.local, the new instance can be named example.cloud2.local. The original AD can be configured to delegate DNS for this domain to the new AD, and users can log in using their existing user@example.cloud.local identities to access resource hostnames like instance1-vc.example.cloud2.local.
  • If the original AD is deployed as a VSI, open a support ticket to ensure that IBM Support decouples the VSI from the original instance. This action ensures that the VSI is not cancelled when the original instance is deleted.
  • In all cases, it is advised to back up the original controllers before you remove the original vCenter Server instance.

Can I use vMotion with vSphere Encryption between the two vCenter Server instances?

With VMware vSphere® encryption, it is possible to perform an advanced cross vCenter vMotion on vSphere–encryption–protected VMs. You need to upgrade the source vCenter to v7.0 or later and connect both vCenters to the same Key Management System (KMS) and assign it the same name. Also, ensure that you have equivalent storage encryption policies in each vCenter Server.

What happens to assets that were deployed manually?

If you added deployed assets to the instance manually, after initial deployment, the automation does not know about them. Therefore, you must migrate the assets to the new instance manually.

I have VMware workloads on IBM Cloud bare metal servers with vSphere 6.5 and 6.7 and the support is ending. I am not using NSX for my workloads. What do I need to do keep the environment supported, and what options do I have?

General support for vSphere® 6.x ended on 15 October 2022. For more information, see End of general support for vSphere 6.5 and vSAN 6.5 or 6.6 and VMware product lifecycle matrix.

Instances with IBM Cloud bare metal servers with vSphere 6.7 cannot be ordered post 21 June 2022. IBM Cloud support for ordering all update levels of vSphere 6.5 ended on 10 October 2021, and vSphere 6.5 cannot be ordered post 21 June 2022.

IBM Cloud recommends an upgrade to vSphere 7.x. If you ordered your servers from the Bare metal catalog for IBM Cloud Classic Infrastructure, you have the following options.

  • Check whether your server and its hardware options are compatible with vSphere 7.0. For more information, see VMware compatibility guide. Alternatively, if you are running vCenter, you can upgrade your vCenter, set up vSphere Update Manager (VUM) or vSphere Lifecycle Manager, and run Hardware Compatibility Checks for the upgrade.
  • Order new IBM Cloud bare metal servers with vSphere 7.x from the Bare metal catalog for IBM Cloud Classic Infrastructure or from the VMware Solutions console, the vSphere offering. Configure your vSphere host and vCenter Server and migrate the workloads. After the workloads are migrated, you can remove the VMware ESXi™ hosts from vCenter Server and decommission the old servers through the IBM Cloud portal.

I have VMware Solutions - VMware vSphere, IBM Cloud bare metal servers with vSphere 6.5 or 6.7, and the support is ending. I am not using NSX for my workloads. What do I need to do to keep the environment supported, and what options do I have?

General support for vSphere 6.x ended on 15 October 2022. For more information, see End of general support for vSphere 6.5 and vSAN 6.5 or 6.6 and VMware product lifecycle matrix.

Instances with IBM Cloud bare metal servers with vSphere 6.7 cannot be ordered post 21 June 2022. IBM Cloud support for ordering all update levels of VMware vSphere 6.5 ended on 10 October 2021, and VMware vSphere 6.5 cannot be ordered post 21 June 2022.

IBM Cloud recommends an upgrade to vSphere 7.x. If you ordered your servers from the VMware Solutions console, the VMware vSphere offering, you have the following options.

  • Check whether your server and its hardware options are compatible with vSphere 7.0. For more information, see VMware compatibility guide. Alternatively, you can upgrade your vCenter Server, set up vSphere Update Manager (VUM) or vSphere Lifecycle Manager, and run hardware compatibility checks for the upgrade.
  • Order new IBM Cloud bare metal servers with vSphere 7.x from the VMware Solutions console, the VMware vSphere offering, configure your vSphere host and vCenter Server, and migrate the workloads. After the workloads are migrated, you can remove the ESXi hosts from vCenter and decommission the old servers from the IBM Cloud portal.

I have VMware Solutions - vCenter Server with NSX-V, IBM Cloud Bare Metal Servers with vSphere 6.5 or 6.7, and the support is ending. What do I need to do to keep the environment supported, and what options do I have?

General support for vSphere 6.x ended on 15 October 2022. For more information, see End of general support for vSphere 6.5 and vSAN 6.5 or 6.6 and VMware product lifecycle matrix.

In addition, the vCenter Server instances with vSphere 6.5 or 6.7 typically run NSX-V 6.4. NSX-V 6.4 was End of General Support on 16 January 2022 and End of Technical Guidance on 16 January 2023. An exclusive support agreement between VMware and IBM to support NSX-V until 31 December 2024 exists.

IBM Cloud recommends an upgrade to vSphere 7.x and NSX-T™ 3.x or later.

To migrate from NSX-V to NSX-T (also called a V2T migration), IBM Cloud uses a migration approach that is called lift-and-shift. In the lift-and-shift approach, the IBM Cloud automation is used to deploy a new vCenter Server instance. You need to migrate network configurations from NSX-V to NSX-T and migrate workloads between instances. IBM Cloud provides extensive documentation for a validated approach and guidance for existing IBM Cloud for VMware Solutions customers with vCenter Server instances.

How do I know whether my IBM Cloud bare metal server hardware is suitable for in-place vSphere 7.x upgrade?

You can check whether your server and its hardware options are compatible with vSphere 7.x. For more information, see VMware compatibility guide.

Alternatively, you can upgrade your vCenter, set up vSphere Update Manager (VUM) or vSphere Lifecycle Manager, and run Hardware Compatibility Checks for the upgrade.

What are the different ways that I can use IBM Cloud bare metal servers for VMware workloads in IBM Cloud?

You can use a VMware® platform on IBM Cloud in the following ways.

  • Bare Metal - Use the Bare metal catalog for IBM Cloud Classic Infrastructure and order a bare metal server with vSphere as the Operating System. For more information, see VMware for Classic.
  • VMware vSphere - Use the VMware Solutions console to provision IBM-hosted VMware hosts. For more information, see VMware vSphere overview.
  • vCenter Server - Use the VMware Solutions console to provision an IBM-hosted private cloud based on vSphere, NSX, and optionally vSAN. For more information, see vCenter Server overview.

Upgrade and migration processes vary depending on the consumption model.

What is the impact if I don't upgrade vSphere 6.x on my IBM Cloud bare metal hosts?

Upgrading your vSphere software is a customer responsibility and the decision to upgrade to a supported version is yours. However, your business might be at risk because VMware is under no obligation to provide product patches and updates, such as security updates and bug fixes. If IBM Cloud provides your vSphere licenses, then IBM Support cannot assist you with vSphere issues until you upgrade.

See also different ways to run VMware workloads in IBM Cloud.

What is the impact if I don't upgrade vSphere 6.x on my VMware Solutions - VMware vSphere (vSS) hosts?

Upgrading your vSphere software is a customer responsibility and the decision to upgrade to a supported version is yours. However, your business might be at risk because VMware is under no obligation to provide product patches and updates, such as security updates and bug fixes. If IBM Cloud provides your vSphere licenses, then IBM Support cannot assist you with vSphere issues until you upgrade.

See also different ways to run VMware workloads in IBM Cloud.

What is the impact if I don't upgrade vSphere 6.x on my VMware Solutions - vCenter Server hosts?

Upgrading your vSphere software is a customer responsibility and the decision to upgrade to a supported version is yours. However, your business might be at risk because VMware is under no obligation to provide product patches and updates, such as security updates and bug fixes. IBM Cloud support for ordering all update levels of VMware vSphere 6.x ended on 10 October 2021 and you can no longer order new vCenter Server instances with vSphere 6.x.

IBM Cloud recommends upgrading to 7.x. If your vCenter Server instance is running NSX-V, consider moving to vCenter Server with NSX-T. This lift and shift upgrade approach can be more beneficial due to the end of support of NSX-V. You might benefit from a target platform with updated hardware, upgraded VMware software, NSX-T, and less of an impact lift and shift migration rather than an in-place upgrade.

See also different ways to run VMware workloads in IBM Cloud.

If I'm using BYOL on my IBM Cloud bare metal hosts, how does it impact the upgrade?

Upgrading vSphere software is your responsibility. However, with Bring Your Own License (BYOL) you can access VMware Support directly by using your license agreement. IBM Cloud provides support for your bare metal servers infrastructure on IBM Cloud.

For more information about upgrading, see VMware ESXi upgrade VMware vSphere 6.7 and vSphere upgrade VMware vSphere 6.5. As part of the upgrade planning, consider moving to the IBM Cloud vCenter Server with NSX-T offering, this lift-and-shift upgrade approach might be more beneficial.

See also different ways to run VMware workloads in IBM Cloud.

If I am using BYOL on my VMware Solutions - vCenter Server hosts how does this impact the upgrade?

Upgrading vSphere software is your responsibility. However, with Bring Your Own License (BYOL) you access VMware Support directly by using your license agreement. IBM Cloud provides support for your bare metal servers infrastructure on the IBM Cloud. For more information, see Upgrading vCenter Server vSphere software from vSphere 6.5 or 6.7 to 7.0. If your vCenter Server instance is running NSX-V, consider moving to vCenter Server with NSX-T. This lift and shift upgrade approach might be more beneficial due to the end of support of NSX-V.

See also different ways to run VMware workloads in IBM Cloud.

What product is it running in the VMware Solutions - vCenter Server instance?

For a vCenter Server instance, the following information is displayed on the VMware Solutions user interface.

  • VMware NSX networking solution - NSX
  • NSX for vSphere - 4.1.0.2
  • NSX license edition - VMware NSX Advanced

What product is it running in the vCenter Server instance?

This vCenter Server instance is running NSX version 4.1.0.2. Due to the licensing agreement between IBM Cloud and VMware, NSX-V licenses were being used for NSX-T instances. Newer vCenter Server instances use NSX-T licenses, so the instance is correctly licensed.

Can I do an in place vSphere upgrade for my vSphere 6.7 with NSX-T VMware Solutions - vCenter Server instance?

Yes, but we strongly advise deploying a new vCenter Server instance and then use the lift and shift migration approach. For more information about the in place vSphere upgrade, see Upgrading vCenter Server vSphere software from vSphere 6.5 or 6.7 to 7.0 and the important considerations.

Also, review the following key considerations:

  • At the end of the documented process, your vCenter Server instance is running vSphere 7.0 Update 1c with N-VDS distributed switches. This configuration is different than the currently supported Software BOM for vCenter Server instances, which is vSphere 7.0 Update 3c with Distributed vSwitch 7.0.0.
  • For more information about the migration of N-VDS to VDS switches for vSphere 7.0 or later and NSX-T Data Center 3.0 and later, see Migrate host switch to vSphere Distributed Switch. Currently, this procedure is not verified on a VMware Solutions vCenter Server instance.
  • IBM Cloud is undertaking an assessment of the N-VDS to VDS conversion and the required changes to the automation database to allow this in-place upgrade.
  • Currently, Day 2 automation workflows such as add host or add cluster, are not tested against VMware Solutions vCenter Server instances that are upgraded from vSphere 6.7 to 7 and still using N-VDS distributed switches. Customers must assume that this automation might fail and that if this automation is required then the lift and shift migration approach used. If this automation is not needed, you can use the upgrade process that is documented.
  • A workaround for the add nodes and add cluster features is to use the VMware vSphere offering. For more information, see VMware vSphere overview. You must complete a number of manual tasks after the automated deployment.
  • A workaround for add-on services is to deploy them manually using the documented reference architectures, see the Solution architectures on Classic and Solution Guides sections at Getting started with VMware Solutions.

Can I reuse the portable subnets that are deployed for my existing NSX-V vCenter Server instance?

When you delete a VMware vCenter Server® instance, the networking (VLANs with private and public subnets) is cancelled together with the IBM Cloud bare metal servers. If you have networking assets in your migration, open a support ticket to ensure that IBM Support decouples the VLANs and related subnets from the original instance. Then, these assets are not cancelled when the vCenter Server instance is deleted.

The following recommendations apply:

  • Design your migration so that you avoid the use of assets from the existing vCenter Server instance, which is to be deleted.
  • If you need any existing assets, note and list all assets carefully.
  • Open the support ticket before you delete the instance. List all assets that you want to maintain to ensure that these assets are decoupled from the original instance. If this process is not followed, the assets cannot be recovered after deletion.

However, if you have overlapping IP addressing challenges, the note the following guidance:

  • You can still continue to use your existing instance management subnet, if it has IP addresses available and you don't use any IP addresses for your own use. The new instance uses new IP addresses for the vCenter server, NSX-T managers, and Active Directory servers (if AD servers are running on the VMware VMs) from the new instance management subnet. Reusing existing management subnet is not possible for these components until you delete the existing VCS.
  • In addition, the NSX-T T0 gateways are provisioned with new IP addresses from the portable private and portable public subnets for customer workload edge. NSX-T T0 gateways do not support secondary IP addresses on their uplinks.
  • You can manually configure an existing subnet for the NSX-T T0 gateway uplinks, but only one subnet can be configured in T0.
  • If you are using secondary IP subnets on the uplinks, you need to redesign the topology. For example, you can order new static subnets and route these subnets to NSX-T T0 HA VIP. These IP subnets and addresses can be used with NSX-T NAT rules, load balancing or on overlay attached VMs.

Can I reuse existing portable subnets that are ordered outside the VMware Solutions console?

If you ordered private or public portable subnets outside the VMware Solutions console, and you use these subnets with your workloads by running on VMware clusters, you can still continue to use these IP addresses if your new instance was deployed on the same VLANs as the existing NSX-V based solution was.

If you are using these IP addresses on ESGs for NAT rules or other services, be aware that the NSX-T T0 gateways do not support secondary IP addresses on their uplinks. The NSX-T T0 gateway in the new instance is provisioned with new IP addresses from the portable private and portable public subnets for customer workload edge. You can manually configure an existing subnet for the NSX-T T0 gateway uplinks, but only one subnet can be configured in T0. If you are using secondary IP subnets on the uplinks, you need to redesign the topology. For example, you can order new static subnets and route these subnets to NSX-T T0 HA VIP. These IP subnets and addresses can be used with NSX-T NAT rules, load balancing, or on overlay attached VMs.