Migrating from IBM Cloud VMware VCF-Automated to VPC VSI with RackWare RMM Tutorial

Before you begin

In this tutorial we migrate an Ubuntu virtual machine and a Microsoft Windows 2019 virtual machine. This tutorial assumes that you have:

1. Read Migrating from IBM Cloud VMware VCF-Automated to VPC VSI with RackWare RMM Technical Guide.
2. Have existing IBM Cloud VMware-Automated instance and hosting virtual machines on NSX overlay segments. These overlay segments do not have native access to the IBM Cloud Classic private network.
3. Created one or more resource groups.
4. Created a VPC with prefixes that cover your required networks.
5. Created a subnet for the RMM server.
6. Created an SSH key and uploaded the public key to VPC SSH keys.
7. Provisioned an RMM server from the IBM catalog.

Create Source virtual machines

First, you need to set up your source virtual machine. This section has examples for the following:

• Ubuntu source virtual machine.
• Windows source virtual machine.

# Format entire disk (no partition table)
sudo mkfs.ext4 /dev/sdb

# Mount it
sudo mkdir -p /mnt/sdb
sudo mount /dev/sdb /mnt/sdb

# Write file
echo "Test content" | sudo tee /mnt/sdb/testfile.txt

RMM Install

Prior to installing RMM, you first set up the VPC infrastructure. At a bare minimum, you must set up a VPC, subnets, and the corresponding virtual server instances that you are planning to migrate. The new target virtual server instance profile (vCPU and vMemory) does not need to match the source. However, for the storage, the target storage needs to be the same or greater than the used space on the source VM's filesystem in size. The RMM's right-sizing option should be used to facilitate this change.

Use the VPC product documentation to:

1. Create a VPC.

2. Create subnet for the RMM server.

3. Create a SSH key.

4. Deploy the RMM server from the IBM Cloud catalog.

   The RMM server has a public IP address for connectivity and a default login.

5. After you deploy, log in to the RMM server.

6. In the RMM server, change the default password, create users, and create an SSH key.

7. Upload the SSH key to IBM Cloud VPC.

You may need to update the RMM version, if so via email to RackWare, request access to their FTP repository and instructions to upgrade

Obtain Licensing from RackWare

1. Obtain licenses from RackWare by emailing the generated preinstall file to RackWare licensing.

2. To generate a preinstall file in /etc/rackware, run the following command using your public key name and IP address.

   ssh -i ~/.ssh/sno3 root@161.156.171.81
   rwadm relicense
   

   Example output is shown below, please note that RackWare recommend installing RMM on RHEL or Rocky 8.x servers:

   CentOS Linux release 7.9.2009 (Core)
   Found supported RedHat/CentOS release.
   CentOS Linux release 7.9.2009 (Core)
   
   WARNING: This command will generate a new preinstall file, but will also INVALIDATE the existing license on next RMM restart.
   If you wish to continue using RMM till you get the new license, DO NOT STOP RMM after running this command.
   Do you wish to continue? (Y/N)  [N]: Y
   PreInstall file generated at /etc/rackware/rwlicense_preinstall_1765474883. Please email this file to licensing@rackwareinc.com to get the license.
   

3. Copy the file from /etc/rackware and send it to licensing@rackwareinc.com as an attachment.

   scp -i ~/.ssh/sno3 root@161.156.171.81:'/etc/rackware/rwlicense_preinstall_*' /Work/2025/RMM/
   

4. After receiving a valid license, download the license file to /etc/rackware and restart the services to apply the license by running the following command, note your filename will be different:

   scp -i ~/.ssh/sno3 /Work/2025/RMM/rwlicense_1765474883_uk_ibm_POC_Mig root@161.156.171.81:/etc/rackware/
   ssh -i ~/.ssh/sno3 root@161.156.171.81
   rwadm restart
   

5. Verify the license by running the following command and return the output to licensing@rackwareinc.com:

   rw rmm show
   

Create a Transit Gateway with connections to Classic and VPC

An IBM Cloud Transit Gateway is a fully managed hub-and-spoke networking service that provides centralized, private connectivity between IBM Cloud infrastructure environments including IBM Cloud VPCs and IBM Cloud Classic infrastructure.

It acts as a routing hub where multiple VPCs and Classic connections attach, allowing traffic to flow securely without requiring complex VPN meshes or manual route management.

Connections to VPCs use native VPC attachments that automatically exchange routes, while Classic connectivity is established via a Classic Infrastructure connection that integrates with the IBM Cloud backbone, enabling seamless private IP communication between VPC subnets and Classic VLANs.

Using the IBM Cloud documentation create a local transit gateway and connect your VPC and your IBM Cloud Classic network. For more information, see Creating a transit gateway.

Order a portable private subnet

An IBM Cloud Classic portable private subnet is a block of private IP addresses that can be assigned to your Classic resources. While you already have a number of subnets associated with your IBM Cloud VMware-Automated instance, the IP addresses on these subnets are assigned by the automation and you should not manually assign IP addresses from these subnets.

It is good practice to order a new portable private subnet and assign IP addresses to virtual machines as needed. This subnet will be used to host the outside interfaces of the one or more RMM bridge servers, therefore, only a small subnet is required.

Using the IBM Cloud documentation order a new portable private subnet in the IBM Cloud Private VLAN named Private management VLAN. For more information, see Customer-owned subnets for Classic.

Assign an IP address for the RMM Bridge Server deployed later in this tutorial.

Order a static private subnet

An IBM Cloud Classic Static Subnet provides a block of IP addresses that are permanently routed to a specific endpoint, in our use case the RMM Bridge Server.

All IP addresses in the subnet are useable e.g. a /30 subnet has 4 useable IP addresses or a /29 subnet has 8 usable IP addresses.

Using the IBM Cloud documentation order a new static private subnet in the IBM Cloud Private VLAN named Private management VLAN and targeting the IP address in the portable private subnet that you will use for the RMM Bridge Server. For more information, see Customer-owned subnets for Classic.

Deploy a virtual machine for use as a bridge server

A virtual machine was deployed on the IBM Cloud VCF-Automated instance with the following specification:

• CPU: 2
• Memory: 1GB
• Hard disk 1: 10GB
• Network adapter 1: T1-192-168-10-0-workload
• Network adapter 2: mgmt-dpg-mgt
• Firmware: EFI
• OS: Ubuntu 22.04
• IP address 1: 192.168.10.254
• IP address 2: 10.134.54.62

1. To access your Ubuntu virtual machine via SSH you may need to configure SSH:

   1. Use the following command to configure SSH.

      sudo nano /etc/ssh/sshd_config
      

   2. Make sure these lines are set:

      PasswordAuthentication yes
      PubkeyAuthentication yes
      ChallengeResponseAuthentication no
      UsePAM yes
      KbdInteractiveAuthentication yes
      

   3. Using Netplan (default on Ubuntu 18.04+), edit your network config:

      sudo nano /etc/netplan/50-cloud-init.yaml
      

      Example configuration with two NICs:

      network:
        version: 2
        renderer: networkd
        ethernets:
          ens192:  # NIC 1 - Inside network
            addresses:
              - 192.168.10.254/24
            routes:
              - to: default
                via: 192.168.10.1
            nameservers:
              addresses: [8.8.8.8, 8.8.4.4]
      
          ens224:  # NIC 2 - Outside network
            addresses:
              - 10.134.54.62/26
            routes:
              - to: 10.0.0.0/8
                via: 10.134.54.1
      

   4. Apply the configuration:

      sudo netplan apply
      

   5. Verify interfaces:

      ip addr show
      ip route show
      

Configure bridge server

This example uses an Ubuntu virtual machine hosted on the IBM Cloud VCF-Automated instance. The virtual machine is deployed with two interfaces.

1. Connect to the virtual machine via SSH:

   1. Update the system with the following command

      sudo apt update && sudo apt upgrade -y
      

   2. Configure IP Forwarding using the following command.

      sudo sysctl -w net.ipv4.ip_forward=1
      sudo sysctl -p
      

   3. Verify the connection using the following command

      cat /proc/sys/net/ipv4/ip_forward
      

   This should return a 1.

   1. Identify Your Network Interfaces using the following command.

      ip addr show
      

      Here is an example of what you might see with that command

      ens192: Source VM network (192.168.10.0/24) - "inside" interface
      ens224: RMM network (10.134.54.0/26) - "outside" interface
      

   2. Configure Static NAT (1-to-1 mapping), such as the following example using VM1: NAT IP: 10.194.177.82, Real IP: 192.168.10.11.

      # Install iptables-persistent
      sudo apt install iptables-persistent -y
      
      # Clear existing rules first
      sudo iptables -F
      sudo iptables -t nat -F
      
      # Enable forwarding
      sudo iptables -P FORWARD ACCEPT
      
      # Static NAT for VM1 (192.168.10.11 <-> 10.194.177.82)
      # Destination NAT (DNAT): Incoming traffic to 10.194.177.82 goes to 192.168.10.11
      sudo iptables -t nat -A PREROUTING -i ens224 -d 10.194.177.82 -j DNAT --to-destination 192.168.10.11
      
      # Source NAT (SNAT): Outgoing traffic from 192.168.10.11 appears as 10.194.177.82
      sudo iptables -t nat -A POSTROUTING -o ens224 -s 192.168.10.11 -j SNAT --to-source 10.194.177.82
      
      # Static NAT for VM1 (192.168.10.12 <-> 10.194.177.83)
      # Destination NAT (DNAT): Incoming traffic to 10.194.177.83 goes to 192.168.10.12
      sudo iptables -t nat -A PREROUTING -i ens224 -d 10.194.177.83 -j DNAT --to-destination 192.168.10.12
      
      # Source NAT (SNAT): Outgoing traffic from 192.168.10.12 appears as 10.194.177.83
      sudo iptables -t nat -A POSTROUTING -o ens224 -s 192.168.10.12 -j SNAT --to-source 10.194.177.83
      
      # Allow forwarding between interfaces for these specific IPs
      sudo iptables -A FORWARD -s 192.168.10.11 -j ACCEPT
      sudo iptables -A FORWARD -d 192.168.10.11 -j ACCEPT
      sudo iptables -A FORWARD -s 192.168.10.12 -j ACCEPT
      sudo iptables -A FORWARD -d 192.168.10.12 -j ACCEPT
      
      # Allow established connections
      sudo iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
      
      # Add IP aliases for NAT addresses on ens224
      # The bridge server owns these IPs directly, so it responds to ARP requests
      sudo ip addr add 10.194.177.82/32 dev ens224
      sudo ip addr add 10.194.177.83/32 dev ens224
      

Generate the RMM’s ssh keys

1. SSH to the RMM Server

   ssh -i ~/.ssh/sno3 root@161.156.171.81
   

2. From the RMM’s console window generate an SSH key pair.

   # Generate RSA key (4096-bit) without prompts
   ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N "" -C "rackware-rmm-server"
   

   Parameters:

   -t rsa: Key type (rsa, ed25519, ecdsa, dsa) -b 4096: Key size in bits -f ~/.ssh/id_rsa: Output file path -N "": Empty passphrase -C "comment": Comment (usually email)

3. Record the public key cat ~/.ssh/id_rsa.pub:

   ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDXA2L3ppb3YQxYQYC2eZon0I7J3Xm/zFMb5PuDHcxKTyFzZzyW6FZlZKM8iQMuO+4bkRVs1nLeqSl3bZR1ubWjaiYyj6cb4BY1/QVR+LNomzfW+hHfohb/MvDsEYNVkhJMHk1vdrZgIjQ5ADRjv2+1D/lUR1j8kHWdM+Bf0ilcuELdZI79iPV+T0umvYPyjtPO1zgkbMgfxh7qAjYkkrdDhbPAY3qvRyyuCrwzrFkmg7zc4QVj370uYDBekWpR9q+6GtGjt9f1Onf0k7CJPKQ1AOG/s+Yho58bK0ogxQJzf45jgfKH/GbOOKlwPzSVbOloajy+lQcepp4lqTKGt354fywwG+ePXFuID9iNJ3w9gsLu94xTjJ5GsB0FPq7V78fUFpKHnuCF5mRMR+mHevKb5oz0E6ANicoKr7yj15vUW0++AtM/qrEp0CbP3giIzQk0TBJsZrodr9vSIfHVPCd3z3/nAWnGhNftnZjw3/LcvUa5KXkuTvw9P5AA5EAXrd9SO77mhsH7+jVkooTI9nQxRnZkTEpPPQFZhZkXhSF/zOndQsX2gQd8/9d5Y+gq3ADo8ykrjgkYcO+J1MwZHlR54MKww+HbZqHDS3ePhphsUHYewldF/n82Ft9/dxUllVAKc9TfDMhyemdmh3yXJhrK8tlDoLB2/qzr4o2o40v9ew== rackware-rmm-server
   

Gather Information about the Source virtual machines

While RMM allows auto-provisioning, where the RMM server will create the target servers in the IBM Cloud VPC with the CPU, RAM, and disk that matches the source server specifications, we are manually creating the target virtual server instance in the IBM Cloud VPC in this tutorial. Collect the source virtual machine specifications and especially the IP address and assigned NAT IP address. For example:

Order the target virtual server instances

1. Follow the IBM Cloud instructions to create the required subnet in the VPC, the CIDR should match the CIDR of the source network.
2. Follow the IBM Cloud instructions to create the required security group in the VPC for the target virtual server instances. Ensure that SSH is allowed from the RMM to the target virtual server instances. For the Windows virtual server instance we will also need to include RDP so that we can connect to the virtual server instance to configure it ready for use by RMM
3. Follow the IBM Cloud instructions to create the required SSH keys in the VPC for the target virtual server instances. As we are provisioning the Ubuntu Target virtual server instance manually, we will need to upload the RMM public key we created earlier and include this when we provision the virtual server instance. This enables RMM to use password-less SSH. For the Windows virtual server instance, this key is used to encrypt the password
4. With the information gathered in the previous step and using the IBM Cloud documentation order the IBM Cloud VPC virtual server instance servers and associated data volumes.

New-NetFirewallRule `
  -DisplayName "Allow SSH (TCP 22)" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 22 `
  -Action Allow `
  -Profile Any

# Create a directory
mkdir C:\<temp_dir>

# Download the RackWare SSHD MSI from the RMM server
curl.exe -k https://<your-RMM-IP-or-FQDN-Address>/windows/RWSSHDService_x64.msi -o C:\<temp_dir>\RWSSHDService_x64.msi

# Install the RackWare SSHD
msiexec.exe /i "C:\<temp_dir>\RWSSHDService_x64.msi" /passive /L*v C:\<temp_dir>\rwsshd.log TARGETDIR="C:\Program Files" SVCUSERNAME="" PASSWORD="" PORT="22" RMMSSHKEY="<RMM_PUBLIC_SSH KEY>"

# Create a directory
mkdir C:\Temp

# Download the RackWare SSHD MSI from the RMM server
curl.exe -k https://10.68.70.11/windows/RWSSHDService_x64.msi -o C:\Temp\RWSSHDService_x64.msi

# Install the RackWare SSHD
msiexec.exe /i "C:\Temp\RWSSHDService_x64.msi" /passive /L*v C:\Temp\rwsshd.log TARGETDIR="C:\Program Files" SVCUSERNAME="" PASSWORD="" PORT="22" RMMSSHKEY="ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDXA2L3ppb3YQxYQYC2eZon0I7J3Xm/zFMb5PuDHcxKTyFzZzyW6FZlZKM8iQMuO+4bkRVs1nLeqSl3bZR1ubWjaiYyj6cb4BY1/QVR+LNomzfW+hHfohb/MvDsEYNVkhJMHk1vdrZgIjQ5ADRjv2+1D/lUR1j8kHWdM+Bf0ilcuELdZI79iPV+T0umvYPyjtPO1zgkbMgfxh7qAjYkkrdDhbPAY3qvRyyuCrwzrFkmg7zc4QVj370uYDBekWpR9q+6GtGjt9f1Onf0k7CJPKQ1AOG/s+Yho58bK0ogxQJzf45jgfKH/GbOOKlwPzSVbOloajy+lQcepp4lqTKGt354fywwG+ePXFuID9iNJ3w9gsLu94xTjJ5GsB0FPq7V78fUFpKHnuCF5mRMR+mHevKb5oz0E6ANicoKr7yj15vUW0++AtM/qrEp0CbP3giIzQk0TBJsZrodr9vSIfHVPCd3z3/nAWnGhNftnZjw3/LcvUa5KXkuTvw9P5AA5EAXrd9SO77mhsH7+jVkooTI9nQxRnZkTEpPPQFZhZkXhSF/zOndQsX2gQd8/9d5Y+gq3ADo8ykrjgkYcO+J1MwZHlR54MKww+HbZqHDS3ePhphsUHYewldF/n82Ft9/dxUllVAKc9TfDMhyemdmh3yXJhrK8tlDoLB2/qzr4o2o40v9ew== rackware-rmm-server"

Prepare the Source virtual machines

New-NetFirewallRule `
  -DisplayName "Allow SSH (TCP 22)" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 22 `
  -Action Allow `
  -Profile Any

# Create a directory
mkdir C:\<temp_dir>

# Download the RackWare SSHD MSI from the RMM server
curl.exe -k https://<your-RMM-IP-or-FQDN-Address>/windows/RWSSHDService_x64.msi -o C:\<temp_dir>\RWSSHDService_x64.msi

# Install the RackWare SSHD
msiexec.exe /i "C:\<temp_dir>\RWSSHDService_x64.msi" /passive /L*v C:\<temp_dir>\rwsshd.log TARGETDIR="C:\Program Files" SVCUSERNAME="" PASSWORD="" PORT="22" RMMSSHKEY="<RMM_PUBLIC_SSH KEY>"

# Create a directory
mkdir C:\Temp

# Download the RackWare SSHD MSI from the RMM server
curl.exe -k https://10.68.70.11/windows/RWSSHDService_x64.msi -o C:\Temp\RWSSHDService_x64.msi

# Install the RackWare SSHD
msiexec.exe /i "C:\Temp\RWSSHDService_x64.msi" /passive /L*v C:\Temp\rwsshd.log TARGETDIR="C:\Program Files" SVCUSERNAME="" PASSWORD="" PORT="22" RMMSSHKEY="ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDXA2L3ppb3YQxYQYC2eZon0I7J3Xm/zFMb5PuDHcxKTyFzZzyW6FZlZKM8iQMuO+4bkRVs1nLeqSl3bZR1ubWjaiYyj6cb4BY1/QVR+LNomzfW+hHfohb/MvDsEYNVkhJMHk1vdrZgIjQ5ADRjv2+1D/lUR1j8kHWdM+Bf0ilcuELdZI79iPV+T0umvYPyjtPO1zgkbMgfxh7qAjYkkrdDhbPAY3qvRyyuCrwzrFkmg7zc4QVj370uYDBekWpR9q+6GtGjt9f1Onf0k7CJPKQ1AOG/s+Yho58bK0ogxQJzf45jgfKH/GbOOKlwPzSVbOloajy+lQcepp4lqTKGt354fywwG+ePXFuID9iNJ3w9gsLu94xTjJ5GsB0FPq7V78fUFpKHnuCF5mRMR+mHevKb5oz0E6ANicoKr7yj15vUW0++AtM/qrEp0CbP3giIzQk0TBJsZrodr9vSIfHVPCd3z3/nAWnGhNftnZjw3/LcvUa5KXkuTvw9P5AA5EAXrd9SO77mhsH7+jVkooTI9nQxRnZkTEpPPQFZhZkXhSF/zOndQsX2gQd8/9d5Y+gq3ADo8ykrjgkYcO+J1MwZHlR54MKww+HbZqHDS3ePhphsUHYewldF/n82Ft9/dxUllVAKc9TfDMhyemdmh3yXJhrK8tlDoLB2/qzr4o2o40v9ew== rackware-rmm-server"

Use the RMM GUI to configure the migrations and perform the initial migration

RackWare RMM follows a phased approach that minimizes downtime through delta synchronization:

1. Initial Replication - Non-disruptive to the origin system; production servers continue running

2. Verification Phase - Test and verify applications in the target environment

3. Delta Sync(s) - Multiple delta syncs can be performed to keep target up-to-date with only changed files

4. Final Sync/Cutover - The actual cutover with minimal downtime. It is recommended that any applications are quiesced, while performing the final delta sync

   Once the source virtual machines has been prepared and the RMM can ssh to them, and the information for the target virtual server instances has been obtained, the virtual machine's workload can be migrated from the source virtual machines to the target virtual server instances using the RMM GUI.

   You can migrate servers one by one or run multiple, simultaneous migrations. If you are running multiple, simultaneous migrations, then download the CSV template from the RMM server and populate the appropriate fields. In this tutorial we will not be using this method.

5. To bring up the GUI, point a web browser at the Floating IP address of the RMM server.

6. Use admin as the Username. rackware is the default Password. If you have not already changed the password for the admin user, do so by using the standard Linux ‘passwd’ command. Press the Login button. The RMM home page will then be shown.

7. This step is only required, if you are using the auto-provisioning feature. Navigate to Configuration, Environments and click Add Environment.

   1. In the form add the following values and then click Add:
      • Name
      • Environment
      • Region
      • API Key

Verification

The replications should complete. Once completed, you can connect to the target virtual server instances and carryout any testing as needed. The source virtual machines are still powered on and functioning. The target virtual server instances are isolated and can be tested without disrupting any production services.

Perform delta syncs

Delta syncs from the source environment to the IBM Cloud VPC virtual server instances capture changes to the source virtual machines since the initial replication was performed.

Cut-over

In this step we quiesce the applications and perform a cut-over/final delta sync from the source virtual machines to the IBM Cloud VPC virtual server instances.

1. Quiesce the applications on the source virtual machines. This step minimizes I/O during the final sync and ensures data consistency:
   • Stop applications/databases on the source virtual machines
   • Log out other users from the system
   • For systems with databases, ensure applications flush outstanding I/O to disk
2. Execute the final delta sync:
   • Trigger the final sync operation through the RMM GUI
   • RMM takes LVM/VSS snapshots (on Linux/Windows respectively) to ensure point-in-time consistency
   • Only changed files since the last sync are transferred (delta sync). This drastically reduces the final sync time to minutes rather than hours
3. Verify Sync Completion:
   • Monitor the wave status in the RMM console
   • Ensure sync completes successfully with no errors
4. Shutdown source virtual machines
5. Network cutover. Redirect user traffic to the new environment in VPC. This step depends on how you have been connecting to your IBM Cloud VMware VCF-Automated instance but could include:
   • routing traffic to the VPC.
   • removing prefix filters from the transit gateway connection.
   • redirecting traffic from the VPN tunnels to the VPC.
6. Post-Cutover Validation:
   • Verify all applications are functioning correctly
   • Check data integrity
   • Monitor performance
   • Test user access

Next steps