Oracle Linux 9 Deployment Fails when using both Cloud-init and VMware Guest Customization
search cancel

Oracle Linux 9 Deployment Fails when using both Cloud-init and VMware Guest Customization

book

Article ID: 424629

calendar_today

Updated On:

Products

VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

When deploying an Oracle Linux 9 Virtual Machine via Aria Automation using a Blueprint that utilizes both VMware Guest Customization Specification (GOSC) and Cloud-init, the provisioned VM either fails to assign an ip or fails to run cloudconfig or both.

Common observations include:

  • The VM is provisioned but lacks network connectivity (no IP assigned).

  • Cloud-init user data/code does not execute or stops midway.

Environment

Aria Automation 8.x

Cause

This issue is caused by a race condition between VMware Tools (handling Guest Customization) and the Cloud-init process.

  1. VMware Tools detects that Cloud-init is running and attempts to wait for it to complete.

  2. However, open-vm-tools times out waiting for Cloud-init.

  3. Upon timeout, VMware Tools proceeds to trigger a guest OS reboot to apply the Customization Specification.

  4. This forced reboot sends a SIGTERM signal to the active Cloud-init process, killing it before it completes the modules-final stage.

 

/var/log/vmware-imc/toolsDeployPkg.log The log shows VMware Tools waiting for Cloud-init, timing out, and then immediately triggering a reboot.

[2026-01-05T06:45:42.070Z] [    info] Cloud-init status is 'running'.
[2026-01-05T06:45:47.070Z] [    info] Timed out waiting for cloud-init execution done.   <------------------------------------------
[2026-01-05T06:45:47.071Z] [   debug] Command to exec : '/bin/readlink'.
...
[2026-01-05T06:45:42.070Z] [info] Cloud-init status is 'running'.
[2026-01-05T06:45:47.070Z] [info] Timed out waiting for cloud-init execution done.
...
[2026-01-05T06:45:47.172Z] [info] Trigger reboot.

 

/var/log/cloud-init.log The log shows Cloud-init receiving a termination signal (SIGTERM) caused by the reboot mentioned above.

2026-01-05 06:45:47,243 - log_util.py[ERROR]: Cloud-init 24.4-7.0.1.el9 received SIGTERM, exiting...
...
2026-01-05 06:45:47,243 - main.py[ERROR]: failed stage modules-final
...
SystemExit: 1
failed run of stage modules-final

 

Resolution

This is a known bug in open-vm-tools. The fix ensures VMware Tools waits longer or handles the Cloud-init status correctly.

Prerequisite:

  • Update open-vm-tools to version 13.0.5 or later.

Configuration Steps: Once the tools are updated on your template, you must configure the timeout parameter to allow Cloud-init sufficient time to complete its scripts.

  1. Edit the tools configuration file on the VM template:

    echo "wait-cloudinit-timeout=300" >> /etc/vmware-tools/tools.conf
  2. Save the template and redeploy.

Workaround

If updating open-vm-tools is not immediately possible, you must serialize the execution logic. The goal is to delay Cloud-init until after the Guest Customization reboot is complete. Here is a sample script that uses this logic:

Strategy:

  1. Disables First Boot: Creates a marker file /etc/cloud/cloud-init.disabled to prevent Cloud-init from running immediately upon the first boot (when vSphere Customization is active).

  2. Delayed Execution: Sets up a Cron Job (@reboot) that waits 90 seconds after the reboot. 

  3. Manual Trigger: The cron job executes a runonce.sh script that removes the marker file and manually triggers the Cloud-init stages (init, modules config, modules final) sequentially. This ensures Cloud-init only runs after vSphere Guest Customization has successfully rebooted the VM.

Note: Refer to the "vSphere Image Preparation Scripts" for sample scripts for the workaround. 

Additional Information

For more details on the bug and the development of the fix, refer to the following Open Source issues:

Powered by Wolken Software