我們在工作中經常會遇到創建雲主機的情況，但是很少遇到給雲主機改主機名的情況。
一台雲主機的 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 的值並不會變化。
聰明的你想到了沒？