A bit off topic...but

Automation/IaC
1

Morpheus doesn’t change the device adapter name right? Like, from ens192 to eth0. I’m asking because we started using cloud-init with Morpheus and it’s creating a second device with eth0 and making it the active device instead of ens192. Just curious if this is something that can be done away with Morpheus side, or should I hunt down a cloud-init forum?

2

Bump. Does anyone know if Morpheus changes the adapter?

3

I opened the entire cloud-init iso for a VM I created.

meta-data

instance-id: morpheus-container-3162
local-hostname: nc-vmware-ubuntu-3081
network-interfaces: |
  auto lo
  iface lo inet loopback
  auto eth0
  iface eth0 inet static
    address 192.168.88.214
    netmask 255.255.255.0
    gateway 192.168.88.1
    dns-nameservers 192.168.88.1 1.1.1.1

network-config

version: 1
config:
- type: physical
  name: eth0
  subnets:
  - type: static
    address: 192.168.88.214
    netmask: 255.255.255.0
    gateway: 192.168.88.1
    dns_nameservers:
    - 192.168.88.1
    - 1.1.1.1
  mac_address: 00:50:56:a5:2a:4e

After looking through cloud-init docs as well, this seems to be the best way to go about it. Naming the interface is required, and the mac is optional. The vast majority of VMs are going to have 1 interface. In Ubuntu 22.04, the interface is named eth0, but the aliases are still enp3s0 and ens160 at least in my lab. In my CentOS and other EL based images, I’m doing some renaming in the udev rules, which may not be required.

1 Like
4

Thanks for your work and looking into this,

The problem is, Redhat doesn’t support systems that don’t use predictive naming. So, if the device is named with an eth0 instead of ens or whatever, then it falls out of support. I’m trying to avoid that and still use cloud-init.

Based on what you showed me though, it appears that cloud-init is doing the rename, and not Morpheus. So thank you for that!

5

I was curious if the same would happen to CentOS 9. I removed all the bits that force bios dev names, and it worked pretty much exactly the same:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:50:56:a5:75:84 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    altname ens160
    inet 192.168.88.217/24 brd 192.168.88.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fea5:7584/64 scope link
       valid_lft forever preferred_lft forever

So at least for RHEL 9, I’d be confident that Morpheus doesn’t require older dev naming, but since we have to call it something according to the cloud-init spec, we name it eth0. Persistent naming is still intact and, IMHO, shouldn’t void any support requirements.

I’m investigating a little further, as I’d like to remove all the complexity I can from our images. In Ubuntu, there were kernel parameters put into the default grub config. In EL variants, there were no kernel parameters, just the udev rules.

6

Nice.

Our current work-around is an ansible playbook that yum remove cloud-init and then mv eth0 to ens192, and changes the devicename inside the file, which is called from a task in Morpheus and reboots. It works, but I’d rather not have the extra steps.

Thank you for time and effort.