Image support for newer Linux OS product

Ideas
,
1

Virtual Image support and documentation for some newer Linux OS product not available

My customer want to use Redhat 9.0, Alma Linux 9.0, and Oracle Linux 8.5, but documentation still not available, still questioning about support ability in morpheus.
As per them, try to replicate procedure with previous version but no luck.
Any roadmap if those OS version will be supported?

2

Could you clarify what you mean by support? Do you mean provisioning instances in Morpheus for those OS versions? Are you looking for system provided images?

We’ve supported deploying EL9 for a few versions now, and that would cover AlmaLinux 9 as well as RHEL 9. That includes the Morpheus Agent.

3

Hi, let me clarify. Customer use Vmware Vcenter and want create own virtual image to provision instance, But as per last doc guide its only have procedure for Centos/Rhel 7 and 8.
Great to hear that, any guide that we can follow to create RHEL9 image on Vcenter?

4

We keep any documentation surrounding the creation of specific OS templates current for use with Morpheus. There are certain guides to do it generally, but a standard RHEL 9 built with packer should work fine.

I don’t do anything special with our images. I simply build a barebones image, and make sure I follow best practices on how to make them cloneable. The only caveat I would have for RHEL is that you have to register them in order to update the RPMs, then remove the subscription before creating a template.

This repository has some good examples for building a RHEL template: GitHub - vmware-samples/packer-examples-for-vsphere: Packer Examples for vSphere

5

@ncelebic, I also was hoping for some specifics for RHEL 9 templates to be used in MD. I deploy these templates just fine with Packer, and they are synced from our VMware cloud config, but when attempting to deploy an instance, I run into oddities with network configuration.

Looking into the issue, I see references to RHEL 8 (specifically) and configuring the networks to use ifcfg-eth0 rather than ens-xxx etc. I am wondering if there is any support for RHEL 9 specifically via MD and “network keyfiles” - especially considering Red Hat strongly recommends the usage of systemd’s naming convention and more recently in RHEL 9 - keyfiles. Any help would be appreciated.

6

@gkelly20, In my testing, you no longer have to rename any of the network interfaces. In the images I have tested, I have no configuration related to that renaming. No kernel parameters, no scripting, the network-scripts package is not installed. The cloud-init network-config script from Morpheus contains something like this:

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

The resulting interface looks like this:

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

The interface is named eth0, since that’s what we default to in the cloud-init config. The persistent naming of the interfaces is preserved in the altname(s) of the interface.

I am not sure what is meant by keyfiles, but I hope this answers some questions.

7