Cloud-init not running when deploying VM templates

Trying to provision VMWare Template. User-data provisioning template works great. Cannot get cloud-init provisioning template to run.

I have this in the template.
datasource_list: [NoCloud]

But the logs show this.

2022-11-14 23:00:38,190 -[DEBUG]: Seed from not supported by DataSourceNoCloud [seed=None][dsmode=net]
2022-11-14 23:00:38,190 -[DEBUG]: Datasource DataSourceNoCloud [seed=None][dsmode=net] not updated for events: New instance first boot

Expected outcome:

Foreman and Proxy versions:

Foreman and Proxy plugin versions:
Foreman 3.24

Distribution and version:

Other relevant data:

Did you ever get this working? Having pretty much the same issue on 3.4.1

i am facing this issues with alma 8 or centos8

its working fine with centos7

It could be that this is due to the vmware-host-tools. These analyse the system and only the enterprise OS versions get support. For example, I got the cloud-init part of openSUSE to work only with an older vmware-host-tools version and a short-term change to a configuration file. Otherwise no IP was assigned to the VM and the cloud-init script could not be downloaded.
I think centos 8 and alma 8 are not in the list of supported OS. Try oracle Linux 8 or RHEL8 for testing.

i thought openvm tools is the which is widely used. that’s what in centos7 is also working not sure can you specific any specific package which is in enterprise and not in open source.

Also, you are saying this is not going to work with open VM tools via foreman its only a problem with package of open-vm tools

kind: user_data
name: UserData open-vm-tools
model: ProvisioningTemplate
- CentOS
- Fedora
- Debian
- Ubuntu
- Almalinux
# Template for VMWare customization via open-vm-tools
    domain: <%= @host.domain %>
    hostName: <%= @host.shortname %>
    hwClockUTC: true
    timeZone: <%= @host.params['time-zone'] || 'UTC' %>

  dnsSuffixList: [<%= @host.domain %>]
  <%- @host.interfaces.each do |interface| -%>
  <%- next unless interface.subnet -%>
  dnsServerList: [<%= interface.subnet.dns_primary %>, <%= interface.subnet.dns_secondary %>]
  <%- end -%>

<%- @host.interfaces.each do |interface| -%>
<%- next unless interface.subnet -%>
  - adapter:
      dnsDomain: <%= interface.domain %>
      dnsServerList: [<%= interface.subnet.dns_primary %>, <%= interface.subnet.dns_secondary %>]
      gateway: [<%= interface.subnet.gateway %>]
      ip: <%= interface.ip %>
      subnetMask: <%= interface.subnet.mask %>
<%- end -%>

ok, I have expressed myself in a misleading way … it is because only the OS supported by VMWare (different ones depending on the ESX version (see the OS list when creating a new VM) are operated via cloud-init, especially the network configuration after a VM has been put into operation for the first time). open-vm-tools only play a role to the extent that they report back to the vCenter which OS the VM has. To “manipulate” this, an older version of open-vm-tools is necessary, as the current ones have changed somewhat here and it is no longer so easy to “fake” a different OS.
If you look in the cloud-init / vmware-* logs you should see something here (unsupported OS messages or something).
Or is your VM assigned an IP at the very first boot and is the VM’s network activated?
But it’s just an idea of mine since I’ve been struggling with it for openSUSE …

Thats one is failing in first boot its not getting an IP and not proceeding for further. So who is owning for injecting IP to VM if we are using cloud init with foreman user-data?

this is the exact behaviour as I know it from openSUSE. The IP injection for clout-init (first boot) comes from ESX / vcenter (some kind of extended VM paramater). You have to manipulate the VM in such a way that an enterprise OS supported by vmware (oracle OS should also work) is reported during OS determination and feedback to the vCenter. only then are the extended parameters transferred. I have not yet found another way to achieve this. It is here as written on vmware and not on foreman / katello

Can we get some source code to look up where we can modify, or is it in open-vm-tools? if you can give some direction on this I can ask some of community members from almalinux to take look as they are saying for rhel 1:1 binary

no, you don’t understand … which OS get the information for a successful cloud init determine vmware! what I do is nothing that may be done officially since i am pregauging a “fake” OS. And almalinux is binary compatible but cannot pretend to be a different OS. The almalinux persons in charge could only try to get vmware to add it to the supported list.