Synchronizing migrated server infrastructure

To make sure that your upgraded server infrastructure and BMC Cloud Lifecycle Management SOIs are synchronized and are always running with updated resources, you can run migrate SDK commands for service instances whose infrastructure servers are migrated across virtual clusters (VCs), VC appliances, clusters, PODs, network centers (NCs), switches, and so on.

For example, suppose an IT infrastructure administrator wants to move all of the virtual machines (VMs), hosts, and resource pools from a source VC to the target VC that is running latest version. Migration has happened across pods, network containers, and switches (standard/DVS). By using the migrate SDK commands, the administrator can make sure that the migrated service offering instances are updated and synchronized with target resources in the BMC Cloud Lifecycle Management portal.

This topic contains the following sections:

What gets updated?

After infrastructure migration, when you synchronize workload migration on a cluster, host, resource pool, or service instance, the following properties are refreshed, and their CMDB relationships are updated:

• Cluster details
• Resource pool details
• Virtual host details
• Compute container NIC details
• Refresh logical networks details
• Update NetworkContainer and NetworkContainer ID
• Refresh virtual guest (VG) NIC
  • Refresh switch 
  • Refresh switch port
  • Update network container
  • Refresh IPAddress (Only DHCP refresh is supported, but NAT is not supported.)
  • Update DNS
  • Update IPAM
  • Refresh network
  • Refresh network zone
  • Refresh disk
    
    • Refresh datastore

To prepare for synchronizing the workload migration of a service instance

1. For the VMware infrastructure, perform these tasks:
   1. Log in to the My Cloud Services console.
   2. Prepare a list of SOIs and their VMs to migrate.
   3. Identify the tool to migrate VC infrastructure servers.
   4. Identify the changes that will occur across the VC after the migration (for example, to networks, VLANs, hosts, clusters, resource pools, switches, and so on).
   5. Migrate the infrastructure servers from the source VC to the target VC.
   6. Make sure that:
      • All of the migrated VMs are up and running on the target VC.
      • All of the migrated VMs are deleted from the source VC.
      • The BMC Server Automation host can reach all of the migrated VMs on the target VC.
2. On BMC Cloud Lifecycle Management, perform these tasks:
   
   • Make sure that:
     • The server (Guest VM) is turned on.
     • Affected VMs are running.
     • All of the resources (clusters and hosts) of the target VC are onboarded in BMC Cloud Lifecycle Management; the corresponding POD and network cluster are created; and proper governance policies are applied.
     • The service offering blueprint is tagged properly with target resources and compute pool in BMC Cloud Lifecycle Management so that all Day2 operation are performed successfully on migrated VMs.
     • The IP of the target VM is not changed if the IPs are assigned statically.
   • If there are any changes in switches, add them to the appropriate pod in BMC Network Automation, and resync the changes from BMC Cloud Lifecycle Management.
   • If there are changes in the VLANs, update the network container blueprint and reprovision the network container. (If needed, you can add a new network container with new network ranges.)
   • Map newly added NCs to the compute pool created for the target cluster and tenant. (Make sure that you are not using the same compute pool to map with the target cluster.)
   • Add the appropriate tagging so that all operations work as expected after the migration.
   • Be aware that:
     
     • The virtualization platforms supported are VMware.
     • Virtual clusters, virtual hosts, and virtual resource pools are synchronized for VMware only.
     • Only dynamic or DHCP IP addresses changes are refreshed. Static IP addresses, even if changed, are not reflected. For more information, see To refresh IP addresses when the NIC is associated with a Load Balancer, a Firewall Rule, or a Network Path.
   • After the infrastructure server migration and before executing a migrate SDK command, flush the DNS cache on the BMC Server Automation host:
     C:/> ipconfig /flushdns

Using SDK commands to synchronize workload migration

You can synchronize workload migration at the following levels:

• vCenter
• Cluster
• Host
• Resource
• Service

Everything under the level you select is migrated. For example, if you use the command to migrate clusters, all of the hosts, virtual machines, and so on are migrated as well.

The following table lists the SDK migration commands.

For complete details about each command, see the "migrate" section in each corresponding topic (cluster, host, resource-pool, or service) under CLM Python SDK reference, or click the links in the table above.

After you use migrate SDK commands, the VM and SOI artifacts are updated in BMC Cloud Lifecycle Management. During the synchronization (refresh), the virtual cluster to which the VMs are migrated is identified through BMC Server Automation. Then, using virtual cluster queries through BMC Server Automation, you can identify all the required components, and the same is updated in BMC Cloud Lifecycle Management.

BMC Cloud Lifecycle Management updates the following entities:

• VC components like clusters, hosts, and resource pools
• Networking pod, switch port, switch
• Network, IP address, DNS, and IPAM
• Data stores

Creating reports before and after synchronization

To create a report to list all of the items that you want to migrate, set the dryrun option to true. For example, the following command does not run the migration, but it generates a file called dryrun_BeforeMigration.csv, which lists the items that will be migrated when you run the command again with dryrun option set to false.

clm cluster-migrate --sourcecluster NAME|id:<GUID> --dryrun true > dryrun_BeforeMigration.csv

When you are ready to migrate, you can run the cluster-migrate command with the dryrun option set to false.