红帽虚拟机修改hostname后不生效，多数情况是配置文件没改全或改错位置，正确做法是同时更新/etc/hostname、/etc/hosts并执行hostnamectl set-hostname，必要时禁用Cloud-init的主机名覆盖。
为什么虚拟机改完hostname还是不生效？
和物理机不同，虚拟机的系统环境多了虚拟化层和初始化工具干预，遇到mysql安装后启动不了这类报错时，大家习惯先怀疑配置，但hostname不生效往往不是配置写错,而是修改链路被截断。
Cloud-init在系统启动时强行回滚了主机名
这是虚拟机场景最常见的坑，OpenStack、VMware和KVM模板创建的虚拟机默认安装Cloud-init，它每次开机都会根据云平台元数据重新设置主机名，如果你只改了系统内部文件，重启后Cloud-init会把名字改回去。
验证方法：
systemctl status cloud-init
服务状态为active,基本可以确认是它在捣乱。
解决方案是编辑/etc/cloud/cloud.cfg：
preserve_hostname: true
有些版本还需要在/etc/cloud/cloud.cfg.d/下新建99_hostname.cfg文件写入同样配置，改完后重启Cloud-init服务，再执行主机名修改操作,顺序不能反。
NetworkManager接管了主机名设置
红帽系Linux从CentOS 7开始，NetworkManager接管网络配置的同时也会管主机名。nmcli命令修改的主机名会写入/etc/hostname，但你手动改文件时,NetworkManager的缓存里还是旧值。
nmcli general hostname new-hostname systemctl restart NetworkManager
这套组合拳能强制同步状态，如果不想重启网络服务，至少执行nmcli general hostname确认当前生效值。
/etc/hosts里残留旧主机名映射
hostname命令读的是内核参数，但很多程序（sudo、su、数据库连接）会先查/etc/hosts解析，文件里还写着旧名字时，终端提示符可能显示新名字，程序日志里却全是旧名字,看起来就像没改成功。
打开/etc/hosts：
0.0.1 localhost localhost.localdomain
::1 localhost localhost.localdomain把旧主机名替换成新主机名，或者删掉主机名映射只保留localhost，这个动作很容易被忽略，但排查linux主机名修改命令行重启失效时,它往往是最后一块拼图。
红帽系虚拟机永久修改hostname的标准流程
市面上流传的临时方案很多，比如用sysctl kernel.hostname，但这只能撑到下次重启，以下流程经过多数生产环境验证，适用于RHEL 7及以上版本。
第一步：检查当前生效的主机名状态
hostnamectl status
这个命令一次性展示静态、瞬态、灵活三种主机名，以及Chassis类型和操作系统版本，先看清现状,避免改完才发现操作系统是小版本的特殊发行版。
第二步：用hostnamectl设置静态主机名
hostnamectl set-hostname your-new-name --static
加--static参数只修改静态主机名，不影响瞬态主机名，瞬态主机名是内核当前持有的，由DHCP或NetworkManager下发，静态主机名才是配置文件里的那个，两者不一致时，终端提示符会随机显示其中一个,给人不生效的错觉。
第三步：同步更新相关配置文件
echo "your-new-name" > /etc/hostname
这一步是双保险，有部分程序绕过systemd-hostnamed服务直接读/etc/hostname文件,所以这个文件必须与hostnamectl设置的值保持一致。
接着编辑/etc/hosts，把原来的主机名替换成新主机名，如果文件里有旧主机名且不处理，部分没有走nsswitch解析顺序的程序会报unable to resolve host错误。
第四步：验证生效情况
执行以下命令逐个检查：
hostname hostnamectl --static cat /etc/hostname
三个命令应该输出相同的内容，如果第三个命令和前面两个不一致，说明还有定时任务或Cloud-init脚本在后台覆盖配置。
第五步：针对性处理无法生效的顽固场景
场景描述：修改命令全部执行成功,但重启后主机名回到出厂设置。
大概率是虚拟机的模板克隆功能在起作用，VMware的Guest Customization和OpenStack的metadata服务都会在首次启动时重置主机名,处理思路是让系统忽略这些外部信号：
sed -i 's/^preserve_hostname: false/preserve_hostname: true/' /etc/cloud/cloud.cfg
如果是容器化部署的环境,还要检查容器编排平台是否下发hostname配置。
重启后hostname又变回去的深层原因
设置好主机名重启又变回去，这个现象在centos修改主机名重启后无效的搜索里高频出现，前面提到的Cloud-init是嫌疑之一,但还有一些更深层的机制。
DHCP让瞬态主机名接管了系统显示
默认情况下，NetworkManager开启DHCP后会使用DHCP服务器下发的主机名作为瞬态主机名，虚拟机在VPC内部网络获取到的主机名通常和物理机的hostname无关,直接沿用虚拟机的名称或IP段命名。
手动修改静态主机名后，重启时DHCP租约更新又带来新的瞬态主机名，如果/etc/hosts解析顺序优先,系统会在两个名字之间来回横跳。
解决方案是屏蔽DHCP下发的主机名：
nmcli connection modify ens3 ipv4.dhcp-hostname your-new-name
将网卡的DHCP主机名参数锁定为自定义值，更彻底的做法是在/etc/sysconfig/network中添加：
HOSTNAME=your-new-name这个文件是RHEL系的老牌配置文件,对兼容性有强迫症的场景可以写。
systemd-hostnamed服务缓存了旧配置
systemctl restart systemd-hostnamed
修改配置文件后建议重启该服务，它负责管理本机主机名的变更并通知D-Bus接口，服务卡在错误状态时，所有主机名修改都会被缓存起来,直到下次重启才释放。
内核参数hostname被直接写入
如果hostnamectl set-hostname执行成功但内核参数没变,用以下命令查看：
sysctl kernel.hostname
输出了旧主机名，说明系统没有正确触发内核参数更新,需要手动补充：
sysctl -w kernel.hostname=your-new-name
但这是临时修改，内核参数重启后从/etc/hostname重新加载,所以最终还是得保证文件内容正确。
验证hostname修改成功的完整性检查清单
走到最后一步，请对照以下清单逐项排查,任何一项遗漏都可能让之前的工作白费。
hostnamectl输出显示新名字cat /etc/hostname内容一致/etc/hosts里没有旧名字残留sysctl kernel.hostname返回新名字- 新开一个SSH会话，终端提示符显示新名字
- 重启一次虚拟机，确认主机名保持新名字
第六点最花时间，但也是最靠谱的验证方式，不少用户改完rocky linux修改主机名不生效后发现，不重启一切都正常，一重启就回到解放前,原因就是配置文件的持久性没做完整。
如果你还开着NetworkManager，注意它的配置文件可能会重写/etc/hostname，在/etc/NetworkManager/NetworkManager.conf中确认以下内容存在：
[main] hostname-mode=static
这能让NetworkManager放弃自己管理主机名，完全交给systemd-hostnamed。
Q&A：关于hostname修改的常见疑问
修改hostname后SSH连接变慢是什么原因？
SSH服务端默认开启UseDNS yes，客户端连接时服务端会解析客户端IP的PTR记录，解析超时导致连接延迟，将/etc/ssh/sshd_config中的UseDNS改为no，然后重启sshd服务，同时确保/etc/hosts中无多余解析记录。
hostnamectl set-hostname和改/etc/hostname文件有什么区别？
hostnamectl命令会同步更新/etc/hostname文件、内核参数和systemd相关状态，是一个完整的处理流程，直接编辑文件只改变了配置文件，需要额外执行systemctl restart systemd-hostnamed才能让子系统感知变化，长期运维建议统一使用hostnamectl命令修改,避免两种方式混淆带来的状态不一致。
CentOS 6等老版本Linux要如何修改主机名？
CentOS 6没有hostnamectl命令，修改/etc/sysconfig/network文件中的HOSTNAME字段，同时执行sysctl kernel.hostname=新主机名立即生效，再同步更新/etc/hosts，CentOS 6的NetworkManager默认不运行，所以改动比较直接，格式是HOSTNAME=node1.example.com这种FQDN写法，但这也会导致hostname输出完整域名而非短名称。