Cloud-init ignoring your config? It’s probably a datasource squabble.

Technical Briefing | 10/22/2026

You spin up a fresh VM, slap your user-data onto it – maybe it’s a script to install an agent, set a hostname, or pull some configs. You boot it, SSH in, and… nothing. The hostname’s wrong, your script never ran, or half your config’s missing. You check the cloud-init logs, everything looks fine, no errors, just… silence. This is a classic cloud-init headache, and I’ve seen it bite sysadmins (myself included) enough times to know it’s rarely a syntax error. More often, it’s a quiet battle between your intended user-data and another, more assertive, configuration source.

What are these “Datasources” anyway?

At its core, cloud-init is about making a generic image unique to its environment. It pulls configuration from different ‘datasources’. Think of them as information providers. When your VM starts, cloud-init pokes around to figure out where it is – Amazon EC2, Azure, Google Cloud, OpenStack, a local config-drive? Each of these environments might provide metadata, network settings, or even user-data in a specific format. It’s designed for flexibility, to work everywhere. But that flexibility? It’s also where the confusion starts, especially if you’re mixing and matching.

• EC2 instance metadata service: The classic, provides instance details, IAM roles, and user-data on AWS. Many non-AWS clouds emulate this for compatibility.
• OpenStack metadata service: Similar to EC2, but specific to OpenStack environments.
• Azure instance metadata service: Azure’s equivalent, delivers VM properties and custom data.
• Config drive: A small, temporary virtual disk often attached to VMs in environments like OpenStack or local KVM, carrying user-data and network configs.
• NoCloud: When no cloud environment is detected, cloud-init can read user-data from /var/lib/cloud/seed/nocloud/user-data or an ISO. Useful for local testing.
• OVA/OVF: For virtual appliances, data can be embedded directly in the OVF descriptor.

When Two Configs Enter, One Config Leaves (Maybe)

Here’s where it gets hairy. cloud-init doesn’t just grab data from one source and call it a day. It probes for all potential datasources. Once it finds one, it might keep looking for others, depending on its configuration. It has a specific order of preference, and this order dictates which user-data takes precedence, or even if your user-data gets processed at all. Say you’re running a VM in OpenStack, but you’ve also attached a config-drive with some specific user-data. Which one wins? The general rule is that the ‘earlier’ (higher priority) datasource found usually ‘wins’ for overlapping configuration items like user-data. But it’s not always a clean overwrite; sometimes parts merge, other times one completely shadows another. This isn’t just theory; I’ve debugged deployments where a default config-drive from an image template silently trampled application-specific user-data provided via the cloud API.

cloud-init analyze datasources

If analyze datasources shows you a datasource you weren’t expecting, or not the one you thought was primary, you’ve found your culprit. You can often influence this behavior. Many cloud-init configurations, particularly within /etc/cloud/cloud.cfg or a vendor-specific override, include a datasource_list. This is a strict ordered list of datasources cloud-init will look for. If your desired datasource isn’t first, or another conflicting one is ahead of it, you’re going to have a bad time. You might need to adjust the image’s cloud.cfg to reorder or disable specific datasources, or ensure your cloud provisioning tool isn’t implicitly adding unexpected ones.

Understanding cloud-init datasource precedence is like having a secret decoder ring for one of its most frustrating behaviors. It’s not a common configuration task, but when you hit that wall where user-data seems to vanish into the ether, this is absolutely the first place you should look. Knowing how to introspect the detected datasources and understanding their priorities saves you hours of head-scratching and log-grepping. Keep this in your back pocket; you’ll thank yourself later when a seemingly uncooperative VM finally bends to your will.