OpenStack keeps resetting my hostname

No matter what I changed, something kept setting the hostname on my vm to Even forcing the /etc/hostname file to be uneditable did not prevent this change. Hunting this down took far too long, and here is the result of my journey.

Old Approach

A few releases ago, I had a shell script for spinning up new virtual machines that dealt with dhclient resetting values by putting overrides into /etc/dhclient.conf.  Find this file was a moving target.  First it moved into


Then to a file inside


And so on.  The change I wanted to make was to do two things:

  1.  set the hostname explicitly and keep it that way
  2. Use my own dnsserver, not the dhcp managed one

Recently, I started working on a RHEL 7.1 system running on our local cloud.  No matter what I did, I could not fix the host name.  Here are some  of the things I tried:

  1. Setting the value in /etc/hostname
  2. running hostnamectl set-hostname
  3. Using nmcli to set the properties for the connections ipv4 configuration
  4. Explicitly Setting it in /etc/sysconfig/network-scripts/ifcfg-eth0
  5. Setting the value in /etc/hostname and making hostname immutable with chattr +i /etc/hostname

Finally, Dan Williams (dcbw) suggested I look in the journal to see what was going on with the host name.  I ran journalctl -b and did a grep for hostname.  Everything looked right until…

Mar 26 14:01:10 cloud-init[1914]: [CLOUDINIT][DEBUG]: Running module set_hostname (<module 'cloudinit.config.cc_set_hostname' from '/usr/lib/python2.7/site-packages/cloudinit...


But…I thought that was only supposed to be run when the VM was first created? So, regardless of the intention, it was no longer helping me.

yum erase cloud-init

And now the hostname that I set in /etc/hostname survives a reboot. I’ll post more when I figure out why cloud-init is still running after initialization.

8 thoughts on “OpenStack keeps resetting my hostname

  1. Alternately, you can disable hostname management in the cloud init config file, or the module uses a template to generate /etc/hosts and you can modify the template.

  2. Cloud-init runs on every boot of the VM and will re-run modules based on the frequency declared in the module. You can modify the cloud-init config file (/etc/cloud/cloud.cfg) to prevent cloud-init from changing your hostname back to the deployed hostname on every boot.

    Your options for this are:
    1. Set preserve_hostname: true
    This will prevent cloud-init from ever setting the hostname, including when the VM is first created.
    2.Remove the ‘ – update_hostname’ line. This will allow cloud-init to set hostname on the initial VM creation but prevent it from changing the hostname back on every deploy.

  3. Another easy way is to just drop a file inside of /etc/cloud/cloud.cfg.d. Call it 99_hostname.cfg and add something like the following:

    hostname: foo

    Then every time it comes up, you can ensure that the hostname is set exactly to what you need it to be. In my organization, some hosts need to have a FQDN and some hosts don’t, so creating a default dhcp_domain could cause more issues than its worth. So, this is an easy fix that users can do as they are deploying their servers.

  4. it was really upto the resolution for facing issue to boot up the VM from snapshot image

  5. and now your password change, resize filesystem and so on is not working, removing stuff isn’t always best idea….

  6. Thanks for the explanations in the comments Joe and Sam. I went with Joe’s solution as well, worked exactly how I wanted it to work. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.