Unsupported content This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Synchronizing migrated server infrastructure

Note

The information in this topic is supported on VMware infrastructure only. The information pertains for BMC Cloud Lifecycle Management 4.6.05 and later.

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:
    • 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.

Note

These commands detect only infrastructure that is designated to be migrated, and the commands update the internal data structure accordingly. Before calling the command, migrate the actual infrastructure using native tools specific to vendors (for example, VMWare).

Command

Description

Migrates infrastructure resources of one or more services from a specified cluster to another cluster across the vCenter. Because BMC Cloud Lifecycle Management retains only cluster information, specify the source and target clusters and --clusterfilter as an input filter.

Migrates infrastructure resources of one or more services from a specified host to another across the vCenter. Because BMC Cloud Lifecycle Management retains only cluster information, specify the source and target cluster and --hostfilter as an input filter.

Before using the host-migrate command:

  • Migrate the host from the source VC to the destination VC.
  • Change the network adapters to target switch ports.
  • Synchronize the host datastore with the target cluster where you have moved the host.
  • Create a datastore cluster of the migrated host datastore on the target VC and create a compute pool of it in BMC Cloud Lifecycle Management.
  • Create a VDR pool of the migrated host datastore into BMC Cloud Lifecycle Management.
  • Make sure that you have created all of the network devices (switches) specific to the migrated host with the target VC credentials in BMC Network Automation and add them into the target VC pod node.
  • Remove the migrated host entry from the source VC.
  • Restart Platform Manager (clear the cache and logs) and wait for some time.
  • Re-synchronize the target VC pod in BMC Cloud Lifecycle Management.
  • Re-synchronize the target VC cluster in BMC Cloud Lifecycle Management.
  • Make sure that the host and its VMs that were moved to the target VC are live and can be browsed in BMC Server Automation.

Migrates infrastructure resources of one or more services from a specified resource pool to another across the vCenter. Because BMC Cloud Lifecycle Management retains only cluster information, specify the source and target cluster and --resourcepool as an input filter.

Migrates infrastructure resources of one or more services from a specified vCenter, cluster, or host to another across the vCenter. Because BMC Cloud Lifecycle Management retains only cluster information, specify the source and target cluster and --servicefilter as an input filter.

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.

Note

When you synchronize workload migration, if any VM is deleted from the virtual center, the synchronize operation fails with the following error:

Could not locate the virtual guest virtualGuestName on target virtualization platform

You must then manually decommission the server or service.

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.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*