CentOS 7+默认启用可预测网卡命名机制，仅mv ifcfg-ens33 ifcfg-eth0无效，因内核启动时仍按PCI/固件生成ens33，忽略配置文件DEVICE值；必须同时禁用net.ifnames=0 biosdevname=0、同步修改配置文件中NAME和DEVICE为eth0、重建GRUB配置并重启。
直接改不生效，必须同时禁用可预测网卡命名机制 + 同步更新配置文件 + 重建引导项，缺一不可。
为什么 mv ifcfg-ens33 ifcfg-eth0 单独执行没用
CentOS 7+ 默认启用 systemd-udev 的可预测网络接口命名（ens33、enp0s3 等），内核启动时会按 PCI 插槽、固件信息等自动生成名称，完全忽略 ifcfg-* 文件里的 DEVICE 值。只改配置文件名或 NAME/DEVICE 字段，系统启动后仍会创建 ens33 接口，而 eth0 不会出现，甚至导致 systemctl restart network 失败。
-
DEVICE="ens33"必须改成DEVICE="eth0"，否则network服务找不到对应设备 -
NAME="ens33"必须同步改成NAME="eth0"，否则ifup eth0会报 “device not found” - 仅靠配置文件修改，无法阻止内核创建
ens33—— 这是根本原因
必须在 GRUB 内核参数里加 net.ifnames=0 biosdevname=0
这是关闭可预测命名的唯一可靠方式。不加这俩参数，后续所有操作都是白忙。
- 编辑
/etc/default/grub，找到GRUB_CMDLINE_LINUX行，在引号内末尾追加空格分隔的net.ifnames=0 biosdevname=0 - 不要删掉原有参数（如
rd.lvm.lv=...、crashkernel=...），只追加 - UEFI 系统需确认 grub.cfg 输出路径：
/boot/efi/EFI/centos/grub.cfg（不是/boot/grub2/） - 运行
grub2-mkconfig -o /boot/grub2/grub.cfg（BIOS）或对应 UEFI 路径命令，否则重启后参数不生效
ifconfig eth0 找不到？检查 udev 规则和驱动加载顺序
即使 GRUB 参数正确，某些虚拟化环境（如 VMware Workstation）或旧驱动下，eth0 可能短暂出现又消失，或被识别为 ens33 后再 rename 失败。
- 重启前先确认 MAC 地址：
ip link show ens33 | grep ether，记下xx:xx:xx:xx:xx:xx - 手动补一条 udev 规则（防兜底）：
echo 'SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx", NAME="eth0"' > /etc/udev/rules.d/10-network.rules - 避免使用
modprobe -r e1000 && modprobe e1000：CentOS 7+ 的e1000驱动通常已内置，强制重载反而可能触发 race condition - 验证是否生效：
dmesg | grep -i "rename\|eth0"，看到renamed from ens33 to eth0才算稳
重启后 ifconfig 仍只显示 lo？别跳过这一步
常见于配置文件未覆盖完整、或 network 服务未读取新配置。不要直接怀疑 GRUB 或驱动。
- 确认配置文件已重命名：
ls /etc/sysconfig/network-scripts/ifcfg-eth0必须存在 - 检查内容：
DEVICE和NAME都是eth0，且ONBOOT="yes" - 手动拉起：
ifup eth0—— 如果报 “device not present”，说明内核根本没创建eth0，回头查dmesg和 GRUB 参数 - 如果
ifup eth0成功但ifconfig不显示，试试ip link show eth0（ifconfig已被弃用，部分 minimal 系统不装 net-tools）
最易被忽略的是：改完 GRUB 后忘记运行 grub2-mkconfig，或者误以为修改了 /etc/default/grub 就等于生效；还有人把 DEVICE="eth0" 漏掉，只改了 NAME，结果 network 服务启动时找不到设备就静默跳过。
