Enable Bare Metal to Bare Metal Migration in IBM Classic Infrastructure Using the RMM Solution

4 min read

Leverage RackWare Management Module (RMM) to move your workload between bare metal servers and between data centers with ease.

Are you limited by your current server hardware? Is your current hardware a few generations behind? Would you like to migrate to a newer generation server to take advantage of the newer CPUs and memory technologies, or do you simply need to relocate to a different data center within IBM Cloud? Have you been concerned and delayed this transition because of the difficulty and possible disruption to your current environment, the lengthy hours of planning required and the actual performance of the migration? Look no further.

RackWare Management Module (RMM), available in the IBM Cloud Catalog, provides bare metal migration solutions that are scalable and easy to consume to help minimize and mitigate the challenges associated with bare metal server migration.

Why use RMM for bare metal to bare metal migrations?

The RMM solution addresses a wide variety of problems that one faces when performing a bare metal to bare metal migration. Some of them can be categorized as hardware incompatibilities, while others are in the inadequacy of tools themselves for executing the migration successfully. Many tools suffer from constraints that RMM can overcome. These are some of these constraints:

  • The ability to migrate servers with or without UEFI capability on source to target machines with UEFI capability. 
  • Support of asymmetric architecture in Intel processors at source and target physical hardware.
  • A plethora of supported hardware drivers that are loaded in RMM to address various hardware combinations in physical servers.
  • Support for pre- and post-migration scripts to manage the custom configurations.
  • Support for delta data synchronization.
  • The ability to migrate not only primary drives or OS drives but all the mounted volumes in the source server, including LVMs.
Migration can be done over the public or private interface. The Transit Gateway provides connectivity from the RMM server to the source and target to facilitate the migration.

Migration can be done over the public or private interface. The Transit Gateway provides connectivity from the RMM server to the source and target to facilitate the migration.

Modes of migration

The default mode of migration is for data to transfer directly to the target from the source; in this case, the RMM sets up a secure (SSH) tunnel between target and source. This is when pass-through mode is disabled. In situations where there is no direct connectivity or communication between the source and target systems due to routing or security rules, there is an alternative mode called pass-through. 

In pass-through mode, the RMM server becomes the bridge for the two systems.  Pass-through mode is a per-wave property that can be enabled or disabled. If it is enabled as in the following screenshot, data traffic flows via the RMM server through a secured tunnel.

The pass-through mode is configurable.

The pass-through mode is configurable.

Bare metal migration in action

  1. Provision the RMM server: Use the IBM Cloud catalog offering and then procure and deploy the license from RackWare. You now have a working instance of the RMM server in IBM Cloud VPC.
  2. Configure the target server: Before you access the RMM GUI, you will need to provision the target server with similar or larger configurations to source.
  3. Secure connections between source, target and RMM server: Create an SSH key-pair on the RMM server. The RMM public key gets copied to the source and target machine for secure data transfer. 
  4. Configure migration wave(s): You can now access the RMM GUI and configure the migration waves. This can be done manually by adding source and target bare metal servers, as shown below, or by uploading a CSV file. The CSV template file can be downloaded from the GUI:
    You can now access the RMM GUI and configure the migration waves. This can be done manually by adding source and target bare metal servers, as shown below, or by uploading a CSV file. The CSV template file can be downloaded from the GUI.
  5. Bare metal preparation: At this time, NIC teaming/bonding is not supported by this solution and if either of the bare metals is configured with NIC teaming/bonding, there is a bit of pre-migration work to do. A case needs to be opened to request that network port redundancy be removed. Check here for more detailed procedure.
  6. Start the migration

RackWare Management Module (RMM) does the heavy lifting

RMM does all the magic in the background once the migration is started between the given source and target bare metal servers, from within the wave configurations. By examining and storing the configurations of source and target server that are used later in the migration stages, it configures the same custom settings as the planned target server, with respect to network interfaces and routing. This is called the “Examine” stage.

After this, the RMM copies to target what is known as the microkernel. It reboots the target into this microkernel and runs like a LiveCD until the time migration happens. The microkernel is the powerhouse of drivers that allows RMM to boot myriad hardware configurations in the target server and then performs the filesystem syncs.

Before the start of the sync, RMM preps the target server in the Setup stage by creating appropriate partitions in disks. RMM allows you to configure or right-size partitions or volumes before the migration is started. There is also the Best Fit algorithm that is used by RMM in the migration job to determine which source disk gets copied to which disk in the target server. Once the filesystems are synced, the target is released and booted back to the migrated version of the source operating system.

The following example shows the migration achieved between source and target Microsoft Windows 2012 bare metal servers that are configured on different hardware configurations. The major difference in Intel processors is UEFI capability on the target server processor:

Microsoft Windows 2012 source running on Intel Xeon-Skylake (4110-SILVER) and target server running on Intel Xeon-Cascade-Lake (6248).

Microsoft Windows 2012 source running on Intel Xeon-Skylake (4110-SILVER) and target server running on Intel Xeon-Cascade-Lake (6248).

Here is another example where a final sync is performed, applications are quiesced at the source and a delta sync is performed. The following screenshot shows the application data (in this case sftp on Debian Linux source) replicated to target Debian Linux and functional on the target side:

The following screenshot shows the application data (in this case sftp on Debian Linux source) replicated to target Debian Linux and functional on the target side:

Depending on application configurations, one may need to finally update the network settings as per the target environment and perform a validation check before releasing the target back to the application owners.

Additional references

  • To get started, access the IBM Cloud’s migration offering here.
  • For more details, access the IBM Cloud technical docs here.
  • For more details on RackWare products, click here.

Be the first to hear about news, product updates, and innovation from IBM Cloud