This article describes steps/workaround to fix 'NETWORKING' issue on the new TARGET VM instance, created by cloning the 'boot' volume of Linux server previously Migrated by RMM.


Background:

<none>


Symptoms:

  1. The network configuration in the Linux Guest operating system still refers to the original MAC addresses.
  2. Mismatch between the MAC addresses in the virtual machine settings and the Linux operating system.
  3. Networking does not work in a cloned Linux virtual machine.


Before you Begin:

You will need to have 'admin' level access to your OCI Tenancy/account 

 

Use case:

Using RMM, Migrate any 'flavor' of Linux VM from On-Prem to OCI (or any cloud) -> Clone its 'boot' volume -> Create a new VM instance from it -> the new VM instance may have 'network' issues.


In our tests, the on-prem OEL 7.x server had eth0, and when migrated to OCI, the target had (gets) ens3.  When cloned, it came up with eth0 instead of ens3 - this didn't match the ifcfg-ens3 config on the 'Cloned' VM and hence the network issues


Applicable To:

The steps described herein illustrates workaround when migrating an OEL 7.x instance from On-Prem to OCI Cloud using RMM v7.4.x.  


Although the exact commands may be different, conceptually, the workaround remains 'similar' regardless of:

  1. Flavor/version of OS as well as the Volume type (must be Supported by RMM per its Pre-Req document) , or
  2. Origin location (example can be on-prem or any RMM Supported Cloud), or
  3. Target Location (example can be on-prem or any RMM Supported Cloud) 


Preparation/Pre-Req:  

  1. To perform these steps, you should be familiar with Linux commands, and
  2. You will need to have 'root' level credential/access to the new TARGET VM Instance within OCI, and 
  3. You should be able to take VNC SERIAL CONSOLE to connect to this new VM Instance you cloned.

 

Suggested Steps:  

(either of these options would work)

Option #1 - rename the ifcfg file on the 'cloned' VM and modify it contents to suit the 'target'


1) mv /etc/sysconfig/network-scripts/ifcfg-ens3 /etc/sysconfig/network-scripts/ifcfg-eth0


2) modify the contents to match the environment - for example, modify the contents so DEVICE is eth0 instead of ens3, comment out the HWADDR (& if present, comment out the UUID as well)


# Generated by RackWare

DEVICE=eth0

#HWADDR=02:00:17:0a:4b:0a

ONBOOT=yes

BOOTPROTO=dhcp

NM_CONTROLLED=no

PEERDNS=yes


3) (if present) delete "/etc/udev/rules.d/70-persistent-net.rules" 


4) Upon reboot, the server comes up just fine with networking



Option #2

1) add net.ifnames=1 to the /etc/default/grub CMDLINE_LINUX parameter


2) then run 

grub2-mkconfig > /boot/efi/EFI/redhat/grub.cfg


3) delete "/etc/udev/rules.d/70-persistent-net.rules" (if present)


4) Upon reboot, the server comes up just fine with networking


 

Post Changes:

A reboot of the CLONED VM is needed.


Important Note(s):

1) We would like to reiterate, the Customer 'scenario' described herein, is outside the normal RMM workflow and hence by its extension outside of RMM Support.


RMM workflow is designed to move from hardware to hardware and configures the system (especially networking) in a specific way for the hardware that it is migrated to. It does not work to make a generic image or template that can be cloned to new hardware where interfaces or other hardware will be different.


2) The options illustrated above are suggestions ONLY based on our internal tests for the OS/Cloud.  There may be other factors in the Target environment that may cause issues, etc., and/or there may be other ways to get over some of these issues.  Customer is welcome to use their own commands and/or methods to resolve the issue. 


3) All changes to be made must be based on and specific to the "Cloned' Target


~ If they have more than one interface, you need to match things to a specific hwaddr.


~ If the name doesn't match the config file (what we are seeing here) without the hwaddr line, it will also fail.


4) In a normal OCI VM Clone workflow the kernel parameters have net.ifnames=1 and the ifcfg-ens3 file, but it would not have HWADDR lines in it, as Cloud init tools available help configure things at boot (like adding ssh keys for example) and hence this issue is NOT seen


5) Similarly, when using RMM's Migration workflow, RMM will perform all such activities and sent up the network behind the scenes and the Target will have no such network issues.


6) The exact commands shown above may differ with each flavor/version of Linux - please refer to appropriate OS documentation for details.