Oracle RAC要求所有节点网卡名完全一致（如均用eth0、eth1），但克隆虚拟机后udev自动生成的70-persistent-net.rules会映射为eth2/eth3，导致PRVG-11050等错误；该文件是硬件映射快照而非配置文件，必须手动编辑——仅保留目标MAC对应规则并修改NAME值，同步更新ifcfg-*文件及HWADDR，再重载udev规则。
为什么/etc/udev/rules.d/70-persistent-net.rules必须手动改
oracle rac要求所有节点的public/private网卡名完全一致（比如都叫eth0和eth1），但克隆虚拟机或重装系统后，udev会按mac地址自动生成规则，把新网卡映射成eth2、eth3——这直接触发prvg-11050或ins-40724错误。系统不会自动覆盖旧规则，必须人工干预。
关键点在于：70-persistent-net.rules不是“配置文件”，而是udev扫描硬件后写死的映射快照。删掉它再重启？系统会重新生成——而且很可能还是错的。所以必须编辑它，只保留目标网卡的规则行，并确保NAME=值准确。
- 先用
ip link show确认当前真实网卡名（如enp0s3）和MAC地址（link/ether aa:bb:cc:dd:ee:ff） - 在
70-persistent-net.rules里找到对应MAC的规则行，把NAME="enp0s3"改成NAME="eth0" - 删掉其他所有含
NAME="eth[2-9]"或无关MAC的规则行——多一条都可能干扰启动 - 保存后执行
udevadm control --reload-rules && udevadm trigger --subsystem-match=net，不重启也能生效（但RAC安装前建议重启验证）
ifconfig down + ip link set name只是临时改名，不能替代udev
有人试过ifconfig eth0 down && ip link set eth0 name em2，发现ifconfig -a里名字变了，但service network restart后又打回原形。这是因为ip link set只改内核态设备名，不触碰udev持久化逻辑，网络服务脚本（如ifup-eth0）仍按原始名加载配置。
更危险的是：如果/etc/sysconfig/network-scripts/ifcfg-eth0还存在，而网卡实际已叫em2，重启network服务会报device not managed by NetworkManager，甚至丢网关。
- 临时改名仅用于调试，不可用于RAC生产环境
- 真正要改，必须同步三处：
70-persistent-net.rules（决定启动时叫什么）、ifcfg-*文件名和DEVICE=值、/proc/sys/net/ipv4/conf/*/arp_ignore等依赖设备名的内核参数（如有） - 改完
ifcfg-eth0后，务必检查HWADDR字段是否匹配该网卡真实MAC，否则启动失败
Oracle 19c RAC对网卡名的校验发生在runcluvfy.sh阶段，不是安装界面
很多人等到图形界面报INS-40724才回头查网卡，其实校验早在runcluvfy.sh stage -pre crsinst就完成了。这个脚本会读/proc/net/dev、解析ifconfig输出、比对/etc/hosts里的IP归属——任何一处设备名不匹配，立刻中断并提示“no matching interfaces”。
注意：runcluvfy.sh默认只检查eth0/eth1，如果你强行用enp0s3，它会直接忽略，导致后续SCAN VIP绑定失败。
- 运行校验前，先手工执行
ifconfig eth0和ifconfig eth1，确认命令能返回有效IP，而不是eth0: error fetching interface information: Device not found - 如果节点间网卡名不一致（如rac1是
eth0，rac2是enp0s8），runcluvfy.sh会在“node connectivity”阶段报错，错误信息藏在cvu_*.log里，搜interface name mismatch - RAC 19c不再接受通配符（如
eth*），必须字面量完全相同——哪怕大小写都不行
改完udev规则后service network restart失败怎么办
常见现象是route add default gw手动加网关后能通，但service network restart一执行，网关消失、DNS失效。根本原因是RHEL/CentOS 7+默认用NetworkManager管理连接，而传统network服务与之冲突。
不要强行kill NetworkManager——RAC 19c的ora.crsd进程依赖它获取动态IP信息。正确做法是让两者共存。
- 停用
network服务：systemctl stop network && systemctl disable network - 用
nmcli重定义连接：nmcli connection modify "System eth0" ipv4.addresses 192.168.1.10/24 ipv4.gateway 192.168.1.1 ipv4.dns "8.8.8.8" ipv4.method manual - 启用连接：
nmcli connection up "System eth0" - 验证：
ip route show default应显示网关，nmcli device status中eth0状态为connected
udev规则改得再准，如果网络服务没切到NetworkManager，RAC安装时仍会因“无法稳定获取IP”失败。这点在物理机部署时尤其容易被忽略。
