IBM Cloud optional services considerations

It is important to understand that any add-on services that you are using in your VMware NSX-V environment are related to that instance. These services are deleted when the NSX-V environment is deprovisioned.

The following list provides the services that you might currently use:

Plan to migrate these services to new services on the VMware NSX-T™ environment.

Understanding metadata

Optional services can be decoupled from the VCF for Classic - Automated with NSX-V instance and reused with VCF for Classic - Automated with NSX-V instance. However, it is important to understand the metadata that the service is using from VCF for Classic - Automated.

Review the following information for Advanced Cross vCenter Server vMotion.

MAC-Address stays the same.
vCenter's MoRef ID for the VM changes. MoRef ID is a unique ID inside vCenter for every object. A MoRef ID is only unique within a VCF for Classic - Automated.
InstanceUUID stays the same. InstanceUUID is generated by the respective vCenter. However, it is preserved across vMotions that occur within the same SSO domain and across an SSO domain.

Veeam

It is possible to decouple your Veeam® instance from your VCF for Classic - Automated with NSX-V instance for reuse with your VCF for Classic - Automated with NSX-T instance. Configuration changes are required to the existing Veeam instance:

Update instance point to the VCF for Classic - Automated associated with the NSX-T environment
Update the DNS setting on the Veeam Server, point to the AD/DNS servers.
Update the default gateway on the Veeam Server, to the high availability VIP IP address of the NSX-T Edge, as access public access is required for license activation.
Update or create a record for the Veeam Server on the AD/DNS Servers that is associated with the new instance.
Update or create an ID or user on the AD/DNS Servers, which will be used by Veeam to access the VCF for Classic - Automated instance.

You must open a ticket to ask IBM Support to decouple the Veeam server, management subnet, and any associated iSCSI storage from the VCF for Classic - Automated with NSX-V instance so that these components are not deleted when the NSX-V instance is cancelled.

If you deploy a new Veeam instance, you must consider backup data and backup configuration to migrate Veeam to the new NSX-T instance.

Backup data - Backup files are hosted in the Veeam repository server. For more information, see Importing Veeam Agent backups.
Backup configuration - The backup configuration can be saved to a file. For more information, see Configuration backup and restore.

If you want to migrate your Veeam service from VMware NSX-V to VMware NSX-T, open an IBM Support ticket by following the steps in Getting help and support.

Caveonix RiskForesight

The primary use case for Caveonix RiskForesight™ is the compliance reporting of the VMware® environment. Therefore, data migration from the NSX-V Caveonix RiskForesight instance to the NSX-T Caveonix RiskForesight instance is not needed.

A secondary use case for Caveonix RiskForesight is the compliance reporting of the workload VMs hosted on the VMware environment. In this case, compliance data for the workload VMs must be migrated to the NSX-T Caveonix RiskForesight instance. You must engage with IBM and Caveonix to plan this migration.

VMware HCX

HCX™ is not being used for DR services, and so no HCX migration to the NSX-T instance is expected. HCX can be used as a migration tool. In this case, the NSX-T instance must be ordered with HCX.

Zerto

It is recommended that Zerto is deployed with the VCF for Classic - Automated with NSX-T instance and that new site pairing is configured along with the required protection configuration.

IBM Spectrum Protect Plus

IBM Spectrum® Protect Plus is not currently available for VCF for Classic - Automated with NSX-T instances. Consider the usage of Veeam instead.

FortiGate Virtual Appliance

FortiGate® Virtual Appliance is available for VCF for Classic - Automated with NSX-T instances.

No migration is required for FortiGate Virtual Appliance.
Capture the existing NSX-V FortiGate Virtual Appliance configuration.
Provision NSX-T VCF for Classic - Automated with FortiGate Virtual Appliance service.
Configure NSX-T FortiGate Virtual Appliance.
Cut-over to the NSX-T FortiGate Virtual Appliance at the required point in the migration.

F5 BIG-IP

F5® BIG-IP® is available for VCF for Classic - Automated with NSX-T instances. The migration approach is to configure F5 BIG-IP in the NSX-T environment in parallel to the existing NSX-V configuration to allow testing. After verification, cut-over to NSX-T F5 BIG-IP appliances.

If you want to migrate your F5 BIG-IP service from VMware NSX-V to VMware NSX-T, open an IBM Support ticket by following the steps in Getting help and support.

Juniper vSRX

Juniper® vSRX is available for VCF for Classic - Automated with NSX-T instances. In the VCF for Classic - Automated NSX-V instance, the Juniper vSRX virtual appliance might be deployed:

On the consolidated or management cluster - The Juniper vSRX protects the traffic to your workload VMs.
On the gateway cluster - The Juniper vSRX appliances protects the vSphere hosts and the workload VMs in the same data center PoD.

The migration approach would be to:

Provision VCF for Classic - Automated with NSX-T with the required Juniper vSRX service option.
Capture the NSX-V environment Juniper vSRX appliance configuration information.
Manually extract the required configuration settings that need to be transferred to the NSX-T environment Juniper vSRX appliances.

Red Hat OpenShift for VMware

Red Hat OpenShift for VMware for NSX-T is available for VCF for Classic - Automated with NSX-T instances. The migration approach summary is as follows:

Provision the VCF for Classic - Automated with NSX-T instance with Red Hat OpenShift for VMware.
Configure the new Red Hat OpenShift for VMware cluster as required.
Create a migration plan, which includes how to handle data from the applications that are being migrated.
Consider using the Migration Toolkit for Containers.

VMware Aria Operations and VMware Aria Operations for Logs

The VMware Aria® Operations™ and VMware Aria Operations™ for Logs service is available for VCF for Classic - Automated with NSX-T instances.

The primary use case for VMware Aria Operations and VMware Aria Operations for Logs is to capture performance, capacity, and logging messages for the VCF for Classic - Automated instance. A secondary use case is to capture performance, capacity, and logging messages for the workload VMs hosted on the VCF for Classic - Automated instance.

The migration approach for the primary use case would be to:

Provision VCF for Classic - Automated with NSX-T with the VMware Aria Operations and VMware Aria Operations for Logs service.
No performance, capacity, or log messages for the NSX-V instance components need to be retained as the instance will be deleted.
When the VCF for Classic - Automated with NSX-V is deleted, the VMware Aria Operations and VMware Aria Operations for Logs service will also be deleted.
Migrate the content of the VCF for Classic - Automated with NSX-V with the VMware Aria Operations and VMware Aria Operations for Logs service to VCF for Classic - Automated with NSX-T by following the Broadcom® documentation.