openstack cloudinit 遇坑记

我们在工作中经常会遇到创建云主机的情况，但是很少遇到给云主机改主机名的情况。

一台云主机的 hostname  一旦确定可能会涉及到很多东西，有些应用是依赖hostname的。

今天devops组的同学发来一个消息，说他想改一台云主机的 hostname，但是改不成功。当时第一个想法就是 为啥要改hostname？难道在创建之前没想好？ 看了一下这台云主机所在的环境，发现是Ultimate环境的，心想，折腾折腾也是可以的。

这台云主机使用的系统是 centos7，该同学使用的是直接修改配置文件的方法来修改的主机名

# 编辑 /etc/hostname 文件
NewVMHostname   # 这里写的是hostname

改完之后，他重启了vm，重启之后发现过了一小会，大概十几秒之后，主机名变成了 原来的主机名 OldVmHostname 。试了几次发现都是这样。（幸亏是虚拟机，一分钟之内就可以完成重启，要是像物理机每次都要十几分钟完成重启，估计要疯了。）

过去看了一下，感觉好奇怪，这样的话，应该是有一个进程去修改了配置文件，这样的话 我应该用 lsof 查看，然而并没有看出什么，估计是进程操作的太快，在我发现之前已经完成了操作，退出了，

那么去看看系统日志吧，在 /var/log/messages中看到了这么几行：

Dec 20 06:19:44 localhost journal: [CLOUDINIT] stages.py[INFO]: Loaded datasource DataSourceOpenStack - DataSourceOpenStack [net,ver=2]
Dec 20 06:19:44 localhost dracut: *** Stripping files done ***
Dec 20 06:19:44 localhost dracut: *** Generating early-microcode cpio image ***
Dec 20 06:19:44 localhost dracut: *** Constructing GenuineIntel.bin ****
Dec 20 06:19:44 localhost dracut: *** Store current command line parameters ***
Dec 20 06:19:44 localhost dracut: *** Creating image file ***
Dec 20 06:19:45 localhost journal: [CLOUDINIT] cc_growpart.py[INFO]: '/' resized: changed (/dev/vda, 1) from 8588886016 to 10732941824
Dec 20 06:19:45 localhost dbus-daemon: dbus[451]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Dec 20 06:19:45 localhost dbus[451]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Dec 20 06:19:45 localhost systemd: Starting Hostname Service...
Dec 20 06:19:45 localhost dbus-daemon: dbus[451]: [system] Successfully activated service 'org.freedesktop.hostname1'
Dec 20 06:19:45 localhost dbus[451]: [system] Successfully activated service 'org.freedesktop.hostname1'
Dec 20 06:19:45 localhost systemd: Started Hostname Service.
Dec 20 06:19:45 localhost systemd-hostnamed: Changed static host name to 'test7.localdomain'
Dec 20 06:19:45 localhost systemd-hostnamed: Changed host name to 'test7.localdomain'

从日志来看，应该是 systemd-hostnamed 启动后，修改了主机名。

那么就这个服务disable掉好了。

systemctl disable systemd-hostnamed.service

接着继续改主机名、重启。结果发现还是不行，在messages里还是看到了 systemd-hostnamed 服务启动了，那么应该是有其他的进程调用了  systemd-hostnamed 服务。

最可能的应该就是 cloudinit 进程了。

查了一下，发现cloudinit 进程可以做的事情中包含这么几件事情。

• setting a default locale
• setting hostname   # 看这里
• generate ssh private keys
• adding ssh keys to user's .ssh/authorized_keys so they can log in
• setting up ephemeral mount points

cloudinit 是有一个配置文件的，在其中可以发现这么几行：

cloud_init_modules:
 - migrator
 - bootcmd
 - write-files
 - growpart
 - resizefs
 - set_hostname
 - update_hostname  # 看到这里 我心里感觉舒心了很多
 - update_etc_hosts
 - rsyslog
 - users-groups
 - ssh

系统启动后，cloudinit 会进行初始化，初始化的时候，会更新主机名，那么这就会导致每次我们重启云主机之后 hostname都会被cloudinit 重设。

我们 只要将  - update_hostname 这一行注释掉就好了。问题解决。

注意：

　　有的同学可能会想到，nova rename 可以修改VM的名字。但是你会发现即使你用了nova rename 修改了 VM 的名字，VM 内部的hostname 并没有变化。这是为什么呢？

这里给你们看一下数据库就明白了：

mysql> select hostname,host,display_name from instances where hostname="Test7"\G
*************************** 1. row ***************************
    hostname: test7
        host: compute10
display_name: test-test

在nova库中的instances 表中，我们会发现这么两个字段 一个是hostname 一个是display_name ，我们使用 nova rename 修改的是 display_name的指，hostname 的值并不会变化。

聪明的你想到了没？