This article explains reasons why, the "OS" in OCI Portal of an RMM Auto-Provisioned Target show “CentOS” when migrating "RHEL" server and a work around for that, even though the TARGET SERVER OS would match the ORIGIN at the end of a successful SYNC.


Background:

When AutoProvisioning/migrating a RHEL (6.x or 7.x or 8.x) to OCI using RMM, the OCI portal shows OS of the TARGET as “Centos” instead of “RHEL”.


Note this does not happen if:
a) Customer chooses to perform a SYNC to Pre-Provisioned Target and chose the matching OS for pre-provisioned Target, as of the ORIGIN, or

b) Customer choose CENTOS (6.x or 7.x or 8.x) or OEL (6.x or 7.x or 8.x) for Migration.  i.e. this problem is limited to RHEL server Migration only.

 

Symptom:

<>

 

Before you Begin:

<> 

 

Use case:

Customer Auto-Provisions/Migrates a RHEL (6.x or 7.x or 8.x) to OCI using RMM

 

Applicable To:  

  1. ANY RMM version on installed in OCI environment. 
  2. Applies when migrating a RHEL (6.x or 7.x or 8.x) to OCI using RMM

 

Preparation/Pre-Req:

  1.  Customer must have met all the PreReqs for ORIGIN/RMM/TARGET for Automatically provisioning a Target.

 

RMM Perspective:

OCI does not provide a RHEL published template (not available in any region) for RMM to use during AutoProvision of Target in OCI.  Hence RMM is left with no choice but to use the equivalent/closest OS available, viz CentOS templates to provision the BASE target image and then perform complete Server migration to it.  


Although upon successful migration, the OS on the TARGET SERVER matches the OS on ORIGIN server, the OCI Portal still continue to show the BASE version, which happens to be CENTOS, in the OCI Portal



Steps/Workaround:  Customer can choose either option - In both cases, upon a successful completion of AP, the TARGET OS will match the ORIGIN OS and the 'OS' for the VM Instance in OCI portal will show the correct "OS". 

  1.  Manually Pre-Provision the Target in OCI with desired OS
    • This requires creating a bare bone TARGET server of OS flavor that matches the ORIGIN OS flavor (does not have to be exact version match) but with matching disk size/layout of the ORIGIN.  
    • Setting up SSH from RMM to the TARGET
    • Configuring the RMM GUI with Target IP and using the ‘Existing SYSTEM’ approach  

This is obviously a very tedious/labor intensive option especially when the number of servers in scope are way too many and hence may not be always desirable

 

  1. CUSTOM IMAGE approach:
    This is an ideal way to resolve the above issue – This involves the following high-level steps:
    • Follow the OCI Standard process and create a custom RHEL image for their RHEL OS (without user/password is preferred although RMM does provide an option to input)
      https://blogs.oracle.com/developers/post/working-with-oracle-cloud-infrastructure-custom-compute-images
    • Import the Custom Image into the same Customer OCI Tenancy where Target is intended to land
    • Configure the RMM to use this CUSTOM image OCID in the OCI Options tab (see the GUI and CLI options below)
    • Perform auto provision of the Target as you usually do 

 

 

GUI Configuration

CLI ‘Equivalent’ Option


[--image-id <OCid>

(Preferred) – Same as --image-name, but using the image's OCID instead of its name.

     Or

[--image-name <name>]

Selects an image to use for provisioning the target machine


 

Post Changes:

<None>

 

Important Note(s):

<None>