No matter what I changed, something kept setting the hostname on my vm to federate.cloudlab.freeipa.org.novalocal. 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
/etc/dhcp/dhclient.conf.
Then to a file inside
/etc/dhcp/dhclient.d
And so on. The change I wanted to make was to do two things:
- Â set the hostname explicitly and keep it that way
- 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:
- Setting the value in /etc/hostname
- running hostnamectl set-hostname federate.cloudlab.freeipa.org
- Using nmcli to set the properties for the connections ipv4 configuration
- Explicitly Setting it in /etc/sysconfig/network-scripts/ifcfg-eth0
- 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 federate.cloudlab.freeipa.org cloud-init[1914]: [CLOUDINIT] stages.py[DEBUG]: Running module set_hostname (<module 'cloudinit.config.cc_set_hostname' from '/usr/lib/python2.7/site-packages/cloudinit...
cloud-init?
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.
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.
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.
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:
#cloud-config
hostname: foo
fqdn: foo.bar.woot
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.
it was really upto the resolution for facing issue to boot up the VM from snapshot image
and now your password change, resize filesystem and so on is not working, removing stuff isn’t always best idea….
Depends on whether you want to do that stuff via OpenStack or if you have another mechanism to manage it.
Joe Solution worked for me, so far so good.
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. 🙂