What is the usage of Cloud-init, post VM provision?

[#1]

What would be the actual usage of cloud-init once the VM is provisioned out of Morpheus?
In other words, can i disable cloud-init safely after the first boot and if i do so will i be losing any functionalities?

Background: We are doing an in-place OS upgrade from RHEL 8 to 9 and due to the standard NIC names(eth0, eth1 and so on) forced by cloud-init for the VMs provisioned through Morpheus, the upgrade fails as it excepts the NIC names to be native e.g. ens192, ens224 etc.

[Ollie-Phillips]

Yup. I had a “moment” there. Sorry. Keep in touch.

[#3]

So to summarize, we can safely disable Cloud-init after the initial VM provision without losing any of the functionalities of Morpheus. Is that right?

Also, is there any way that we can prevent Cloud-init(other than disabling) from renaming the NICs to some weird names added after provision?

Thanks.

[Ollie-Phillips]

It is one of the Morpheus Agent installation methods. So if you came back to a VM provisioned without the agent, to later add it, cloud-init would not available for that operation. But there are other methods including manual for that, but that’s the only thing that springs to my mind.

[#5]

Thanks Ollie. Even i guessed so!

[#6]

Thanks, and we pretty much use VMware tools and in some instances the agent install script.

[KoreyG]

To add to what @Ollie_Phillips mentioned, cloud-init only gets used at the time of provisioning. This functionality can be changed on the cloud here:

When installing the agent after it is up and running, it will use the RPC methods (SSH/WinRM/VMTools/Azure Run) configured on the cloud:

Alternatively, you can download the agent install script and run it in the guest OS directly. In any case, we would not use cloud-init once it is up running though.

@ncelebic may be able to help more with his question above too, on the use case.

[#8]

Which platform is this on? AWS? VMWare?

On VMWare and more recent versions of RHEL and variants, I’ve found that our cloud-init config adds an alias to eth0 and doesn’t completely rename the interface.

[#9]

I haven’t dug in a great deal to multiple NICs and those effects. I had, apparently wrongly, assumed it would be the same effect. It’s probably due to the fact that during creation, RHEL writes an initial config for the first NIC based on the system it was created on using consistent device naming.

When Morpheus adds additional NICs, we can’t determine what the consistent name would be, so in cloud-init we name it as ethX.

[Ollie-Phillips]

Actually, think I may have mislead you. It is a method for agent install, but wouldn’t be used to install agent later, only during provision. My apologies there. Hopefully one of my colleagues can add further context here.

[#11]

This is on VMware specific to RHEL8 distro. I read the KB article that from RHEL 9 on we don’t have to rename the NICs as it will be handled as aliases and i have tested this too.
Problem is with RHEL 8 and below where Morpheus/Cloud-init renamed the additional NICs that we add to the VM. For instance we have a standard to provision all VMs with 2 NICs and some of them may need a 3rd NIC depends on the app hosted and when we add the 3rd one it comes with the next available name eth2 but once you reboot the VM, eth2 get renamed as cirename0 and the communication through that NIC gets disrupted. I’m looking for a fix to overcome this behavior. Thanks.