在虚拟机里用udev“直接写死”IP并不是推荐做法；更稳妥的配置是让udev只负责网卡命名或事件触发，把固定IP交给NetworkManager、systemd-networkd、netplan这类网络管理栈持久化。 先把职责边界摆清楚，后面命令才不会白敲。
虚拟机udev配置固定IP地址怎么操作？先分清“管设备”和“管地址”
udev的强项是处理设备事件,网卡出现、消失、改名，它都能第一时间感知，可IP地址的分配、路由、DNS、开机自启顺序，属于网络管理栈的活，把两件事混在一起，短期能通，重启后却容易丢地址。
据systemd项目文档,udev负责设备节点和事件规则，不负责网络地址的生命周期管理，这句话很关键，你可以用udev规则匹配网卡MAC，给接口一个稳定名字，也可以在规则里调用脚本；但生产环境更推荐把地址写进网络配置文件。
常见误区有三个：
- 在udev的
RUN里直接执行ip addr add，以为重启后还会生效。 - 网卡名从
ens33变成ens34，配置文件没跟着改，固定IP自然失效。 - NetworkManager和自定义脚本同时管一张网卡,后启动的把先配置的覆盖掉。
比较稳妥的固定IP链路是：先让接口名稳定，再让网络管理服务持久化地址，最后用重启验证，业内专家指出，排障时把设备事件和网络状态分开看，定位速度会快很多。
| 做法 | 地址持久性 | 排障难度 | 适用场景 |
|---|---|---|---|
udev规则里直接ip addr add |
依赖事件触发，易被覆盖 | 高 | 实验、临时测试 |
| NetworkManager/nmcli | 高 | 低 | 桌面虚拟机、通用服务器 |
| systemd-networkd | 高 | 中 | 精简服务器、云镜像 |
| netplan | 高 | 中 | Ubuntu虚拟机 |
| DHCP按MAC保留 | 高 | 低 | 需要集中管理地址的环境 |
VMware虚拟机网卡固定IP配置方法：udev定名，网络栈定址
VMware虚拟机克隆后,网卡名和MAC容易变化，先确认MAC，再决定要不要用udev或.link文件固定名称，地址部分交给NetworkManager，维护成本更低。
第一步：确认网卡MAC和当前接口名
在虚拟机里执行：
ip link show cat /sys/class/net/ens33/address udevadm info -q property -p /sys/class/net/ens33
记下ID_NET_NAME_MAC、ID_NET_NAME_PATH和MAC地址，后面写规则时，MAC要小写，冒号格式保持一致。
第二步：写udev规则固定网卡名
旧环境可以用udev规则：
sudo vi /etc/udev/rules.d/70-vm-net.rules
示例：
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:0c:29:aa:bb:cc", NAME="ens-vm0"
加载规则：
sudo udevadm control --reload-rules sudo udevadm trigger --subsystem-match=net --action=add
较新的systemd环境更推荐.link文件，路径是/etc/systemd/network/10-vm-ens.link：
[Match] MACAddress=00:0c:29:aa:bb:cc [Link] Name=ens-vm0
然后执行sudo udevadm control --reload和sudo udevadm trigger --subsystem-match=net，如果系统里还有旧的70-persistent-net.rules，别让两套规则同时抢着改名。
第三步：用NetworkManager配置固定IP
接口名稳定后,用nmcli写地址：
nmcli connection show sudo nmcli connection modify "Wired connection 1" \ ipv4.method manual \ ipv4.addresses 192.168.56.10/24 \ ipv4.gateway 192.168.56.1 \ ipv4.dns "223.5.5.5 1.1.1.1" \ connection.autoconnect yes sudo nmcli connection up "Wired connection 1"
这里的168.56.10/24只是示例，实际要按虚拟网络网段改，VMware NAT模式、桥接模式、仅主机模式的网关不同，别直接照搬。
第四步：重启验证
ip -4 addr show ens-vm0 ip route nmcli device show ens-vm0 ping -c 3 192.168.56.1 sudo reboot
重启后再看一次地址和路由,只有重启后仍稳定，才算固定IP配置完成。
Ubuntu虚拟机udev配置固定IP地址步骤：规则只做触发和命名
Ubuntu 22.04、24.04常见组合是netplan加NetworkManager或systemd-networkd，udev规则可以保留，但让它做触发和命名，地址写进netplan更清晰。
用netplan写静态地址
编辑/etc/netplan/01-vm-static.yaml：
network:
version: 2
ethernets:
ens-vm0:
match:
macaddress: "00:0c:29:aa:bb:cc"
set-name: ens-vm0
addresses: [192.168.56.10/24]
routes:
- to: default
via: 192.168.56.1
nameservers:
addresses: [223.5.5.5]
应用配置：
sudo chmod 600 /etc/netplan/01-vm-static.yaml sudo netplan try sudo netplan apply
YAML缩进只用空格,不要用Tab。netplan try会给你一次回滚机会，适合远程虚拟机。
用udev规则触发脚本的写法
如果确实要让udev在网卡出现时执行动作,规则可以这样写：
ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:0c:29:aa:bb:cc", RUN+="/usr/local/sbin/vm-static-ip.sh"
脚本里用绝对路径,保持幂等：
#!/bin/sh set -e IFACE="ens-vm0" /usr/sbin/ip link set "$IFACE" up /usr/sbin/ip addr replace 192.168.56.10/24 dev "$IFACE" /usr/sbin/ip route replace default via 192.168.56.1 dev "$IFACE"
赋予执行权限：
sudo chmod +x /usr/local/sbin/vm-static-ip.sh sudo udevadm control --reload-rules sudo udevadm trigger --subsystem-match=net --action=add
这套写法适合实验环境,生产环境要面对服务启动顺序、DNS被覆盖、多网卡路由冲突等问题，维护成本不低。
systemd-networkd的对比写法
如果系统用systemd-networkd，可以写/etc/systemd/network/10-ens-vm0.network：
[Match] MACAddress=00:0c:29:aa:bb:cc [Network] Address=192.168.56.10/24 Gateway=192.168.56.1 DNS=223.5.5.5
然后执行sudo systemctl enable --now systemd-networkd，NetworkManager和systemd-networkd尽量二选一，别让两个服务同时管理同一张网卡。
云服务器虚拟机udev固定网卡名称设置静态IP的注意点
云上虚拟机和本地VMware不一样,MAC可能因热迁移、重建实例变化，公网IP通常由云平台映射，不建议在guest内部硬改公网地址，北京机房、华东云节点这类场景里，先看云厂商网络模型，再决定是否固定网卡名。
- 用
ip -o link和udevadm test /sys/class/net/eth0确认命名依据。 - 优先匹配
ID_NET_NAME_PATH或PCI槽位，别只盯着MAC。 - 检查cloud-init是否会覆盖网络配置，必要时在
/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg里关闭网络配置接管。 - 内网静态IP优先用云平台私有网络或DHCP保留,guest内配置只做辅助。
- 改完后用
cloud-init clean和重启验证，避免下次开机被元数据改回去。
行业共识认为,云环境里的地址配置要尊重平台网络层，guest内脚本只解决guest内的问题，把udev规则当万能钥匙，后面排障会很被动。
不花钱的udev固定IP方案值不值得用？成本与风险对比
这套思路的吸引力在于零额外授权成本,测试环境里很香，代价是隐性维护成本：脚本要自己保证幂等，服务顺序要自己排，DNS和路由要自己兜底。
| 方案 | 成本感受 | 稳定性 | 建议 |
|---|---|---|---|
| udev规则加脚本 | 不花钱 | 一般 | 临时实验、离线测试 |
| NetworkManager | 系统自带 | 高 | 通用虚拟机 |
| netplan | 系统自带 | 高 | Ubuntu服务器 |
| systemd-networkd | 系统自带 | 高 | 精简系统、云镜像 |
| DHCP MAC保留 | 平台功能 | 高 | 批量管理 |
据统计,多数固定IP失效案例不是命令写错，而是配置被另一个网络服务覆盖，先停掉冲突服务，再谈规则怎么写。
虚拟机udev固定IP常见问题解答
udev规则里写了ip addr add，为什么重启后IP丢了？
常见原因是NetworkManager或systemd-networkd后启动，把地址覆盖了；也可能是udev的RUN执行环境PATH受限，ip命令没找到，把ip写成/usr/sbin/ip，并检查journalctl -u systemd-udevd -b，更稳的做法是把地址写进网络管理配置文件。
固定IP必须改udev规则吗？
不必,只有接口名漂移、需要按MAC稳定命名时，才考虑udev规则或.link文件，地址固定用NetworkManager、netplan、systemd-networkd都能完成；DHCP按MAC保留也能达到类似效果。
虚拟机和物理机udev配置固定IP有区别吗？
物理机更关注网卡名稳定和硬件槽位；虚拟机还要考虑克隆后的MAC冲突、云平台元数据接管、热迁移后MAC变化，udev负责设备事件，地址配置由网络管理栈持久化，这条边界在虚拟机和物理机上一致。