IBM Cloud classic bare metal to classic bare metal migration

RackWare Management Module (RMM) solution simplifies the overall migration process of moving the operating system, applications, and data from one bare metal server to another in the IBM Cloud® classic environment. The migration can occur either over the public or private interface of the compute resource. The only requirement is that RMM must be able to access both source and target server over SSH.

Objectives

Prepare the source and target servers
Learn what is needed for the supported network topology
Learn how to use the RMM solution

Limitations

Encrypted volumes are not supported.
Do not modify the target. If anything is modified out of control of RMM after the first migration, it can be wiped out and the result can be unexpected.
The RMM solution handles only the OS, application, and data movement, so anything else needs to be set up by you (for example, security groups, subnets, and so on).
For data migration, File Storage for Classic is not supported. You can use third-party tools such as rsync for data migration on block and file.

Supported operating systems

RHEL 8.x, 9.x
CentOS Stream 9
Debian 11, 12
Ubuntu 20.04, 22.04, 24.04
Rocky Linux 8, 9
Fedora CoreOS 40
SUSE Linux Enterprise server 12, 15,
Windows 2016, 2019, 2022

Supported topology

Migration can be done either over the public or the private interface. While RMM uses SSH to communicate with the servers, migrate by using the private address. In addition, you get to use IBM's network during migration over the private interface.

Because RMM is deployed in IBM Cloud VPC, it requires a transit gateway for the RMM to communicate with the source and the target server over the private interface. The source and target server also need to be able to communicate with one another.

If the source and target server do not have direct communication, then use the pass-through method of data transfer. The RMM server acts as a proxy, and the migration flows through the RMM server. RMM does not store a copy of the used data from source hosts.

To create an IBM Cloud Transit Gateway and establish a connection between classic and VPC, review the following information:

For transit gateway and classic, you need to follow two steps:

Enable VLAN spanning to allow communication between subnets and data centers in classic. For more information, see VLAN spanning.
To allow communication between VPC and classic, both transit gateway and enabling VRF in classic are necessary. For more information, see Planning for IBM Cloud Transit Gateway.

Topology — Network topology of RMM and bare metal migration

This architecture diagram is applicable for bare metal to virtual server and virtual server to virtual server scenarios.

Before you begin

For each volume on the source server, 20 percent of the unused space must be available to store the snapshot that is created by RMM.
Copy the RMM SSH public key to both the source and target.

a. This process can require modifying the servers' host route table or security rules.

b. Update the name server or DNS.
The order of the target server, the CPU, and memory does not need to match, but the volumes must be equal or greater than the source.
Make sure to have /etc/fstab entry for automatic mounting of any file system on the target server.

Order RMM

The RMM tool is available in the IBM Cloud catalog. After you order, a virtual server with RMM software is installed into your VPC of choice. The RMM server has a public IP address for reachability and a default login.

If public IP address is not attached to RMM server, then its 'Reserved IP' address can be used to access RMM server with bastion host.

Order the RMM server from the IBM Cloud catalog.
After you order, log in to the RMM server.
In the RMM server, change the default password, create users, and create an SSH key.
Upload the SSH key to IBM Cloud VPC.

Order a license

The license required for migration to IBM Cloud is Bring Your Own License (BYOL). You need to purchase the license directly from RackWare.

Follow these steps to get a license:

Order your license from RackWare.
Run the following command on the RMM CLI to generate a preinstall file:
```
rwadm relicense
```
After the preinstall file is generated, send a license generation request to the RackWare licensing team with the following information:

a. RMM license (subject line)

b. Company name

c. License count

d. Preinstall file (attached)

e. Purchase order (attached)
Install the license.

a. After the valid license is received, download the license file and place it in /etc/rackware. Restart the services to apply the license by running the following command:
```
rwadm restart
```
b. Verify the license by running the following command:
```
rw rmm show
```

Prepare source and target servers

Before you can begin, you need to do a few things on the source and target device for the migration:

The RMM server needs to connect with servers that use SSH; thus the RMM public SSH keys need to be copied on both the source and target servers.
If the source device has both public and private interfaces, host routes need to be added to ensure the communication between the source and target servers. The routing is done over the transit gateway path. Complete the following steps to prepare your relevant servers:

Linux systems

Copy RMM SSH public key to both the source and target servers.

Windows systems

Copy the RMM SSH public key to both the source and target servers.
You need to download the SSH key utility. You can download it from the RMM server: https://<RMM IP>/windows/RWSSHDService_x64.msi
You are SYSTEM, and you need to key in the RMM SSH key to authenticate for both the source and target servers.

Set up RMM waves

You can migrate servers over one-by-one or perform simultaneous migrations. If you are performing multiple, simultaneous migrations, download the CSV template from the RMM server and complete the appropriate fields.

Log in to the RMM server.
Create a Wave and define the Wave name.
If you have multiple hosts, download the template, complete the appropriate fields, and then upload the template.
Select the Wave name to enter source and target information.
Select the "+" sign.
Add source IP address or FQDN and add source username.
Target Type = Existing system
Sync Type = Direct sync
Add a target IP address or FQDN.
Add a target-friendly name, and add a target username.
Start the migration.

The username field for Linux environments is root. The username field for Windows environments is SYSTEM.

Migrate

After the source and target host are added in the wave and replication record, click the Sync Options tab. Select the No Transfer option, and click Modify. Then, click the play icon to start replication. This action performs a dry run by checking the connection between the RMM, the source, and the target servers. This action doesn't migrate data. If the operation is successful, then remove the No Transfer option that uses the same process.
Whenever you are ready, go ahead and click start replication (the play icon ). This action starts the actual migration. If you expand the replication record, it displays the actual steps as they are run in summary with necessary information.
Whether the operation is successful or not, you can see the job history in the replication record.
If the operation failed, you can retrieve the log and review detailed information.

To improve data transfer rate, adjust bandwidth allocation of RMM server. To know how to change bandwidth allocation, see Adjusting bandwidth allocation by using the UI.

Validate your migration

After your migration, validate the target server. The following list is not exhaustive, but suggests some of the items to validate:

Access the target server.
Check partitions and volumes.
Check applications.
Install any test application in the target server.
Check networking routes.
Check or update application or operating system licenses.
Remove RMM SSH key.