前几天发了个“帖子：关于 All In Boom 到底是 Boom 在哪里？”探讨 All in boom 潜在的问题后得到的结论是不折腾软路由然后多备份就能够避免绝大多数 Boom 的情况了，然后这几天就 Boom 了一下，或者也可以说是我对 Linux 的经验不足导致的。
长话短说：给 PVE 宿主机新增了一个 PCIe 转 Sata 卡导致网卡名称变化进而导致 VM 断网。
前面的帖子里面提到 PVE 的好处就是可以非常方便的给 VM 进行备份，唯一麻烦的一点就是要如何将 Nas 的 VM 备份到 Nas 自己里面这种类似递归或者自举一般的操作。最简单并且省钱的办法就是给 PVE 宿主机一块独立于 Sata 控制器的硬盘，所以从柜子里翻出了积灰已久的 PCIe 转 Sata 卡插了上去。
这个行为触发了“可预测名称机制”，非常反直觉的，并且不可预知的改动了网卡的命名！
主板有两个网卡 enp2s0 和 enp3s0 被改动成了 enp3s0 和 enp4s0 ，由于虚拟机的 vmbr0 是桥接到宿主机的 enp2s0 上的自然就断网了。而 PVE 宿主机的网卡 Mac 显然不会变化于是最终通过重命名后的 enp3s0 获得了之前在硬路由上设置好固定 IP 。
虽然能排查并解决但配置/排查各种问题很难称得上是有生产力的行为，尤其当你是一个开发者而不是一个运维人员的时候。本该写点代码修点 BUG 结果被这个问题消耗了半天。
对于还在摸索和熟悉 Linux 的人而言这个问题是完全“不可预知”的并且这个坑一定会踩的，独自一人走完全陌生的夜路却熟悉路上的每一个角落是互相矛盾的事不是么？这些不算大的问题和反直觉的设计结合起来使得 Linux 系统本身难以普及到非技术群体，只有二次封装的 Nas/Android 等系统才能用。
多少有点发牢骚了，大家就当看个热闹了。

我是匹配 pci Path 或者 mac 地址之后自己取别名的

最后也只能这么做，但这个设计真的算不上“用户友好”

网卡名称由于新设备插入而变更是常规操作，也很合理。如果需要固定某一设备的名称，请使用 udev 来修改，我司所有在用的网口都使用 udev 来固定的。

不动 pcie 设备位置网卡名字也会变的么？
其实前几年一直用的 ethx 换了新设备变成了 enpxsx 还觉得挺奇怪，就查了一下原来跟 PCI 接口位置有关

我也遇到过，哈哈哈 加了个硬盘，然后 pve 断网了

常规 BUG： /t/971968
不知道的人只能重装系统了

pve 日常，有次有个 nixos 机器重启一下发现 ip 变了，定位一通发现网卡名已经不是配置里指定的那个了。。

插拔 PCIe 设备会导致网卡名称变化，ethx 是旧版本的网卡名称 enpxsx 则是新特性，关键词可以去搜索 Predictable network interface names 相关资料。

顺带吐槽一下虽然这个机制翻译过来叫“可预测网络接口名称”，但实际使用中基本和“预测”这俩字无关。

＃8 我还遇到过改直通导致网卡名称变化

应该是 PVE 专属 BUG ？

debian 13 未复现，已有 enp4s0 （ 10G ）的情况下加了一张是 enp4s1 （ 1G ），交换两张卡位置后也确实变成了 enp4s0 （ 1G ）和 enp4s1 （ 10G ）

好像新版本有改进这个网卡名称的问题

可以用 Predictable network interface names 作为关键字搜索，就目前我找到的资料都是把这个当成一个 feature 或者新机制的，而非当成一个 bug

我使用的是 PVE 9.0 按理说已经是最新的系统了

我上周加了个双口网卡导致管理口从 enp3s0 变成 enp9s0 ，新网卡上一个口变成了 enp3s0 ，直接导致 PVE 宿主机连不上

直接使用可预测网卡名称会导致网卡名称不可预测。

解决方法也很简单，用 PVE 常年以来都有的固定网卡名称功能就行了。

proxmox-network-interface-pinning generate
proxmox-network-interface-pinning generate --interface enp4s0 --target-name nic10g1

然后 PVE 会创建关联文件，通过 MAC 映射网卡到固定名称。

[直接使用可预测网卡名称会导致网卡名称不可预测] 这句和黑色幽默一样

这个应该是消费级主板才有的问题，因为可预测名称是按 PCI 编号来的，很多消费级主板新增减少 PCIe 设备会改变编号，服务器主板应该是真的可预测

作为一个普通的软件开发者觉得这块明显设计有问题。

你看上面有些应该是有运维经验的大佬都提到他们公司是使用了 udev 来固定网卡名称，或者使用 pve 自带的功能来固定网卡名称，这说明固定网卡名称确实是一种更常见的需求，同时企业级的设备也需要固定网卡名称。

我的想法是，如果一个功能的最终下场是让大家不要使用这个功能，那么这个功能一开始就不应该存在或者应该有更好的设计。

这个特性当然是有意义的，以前哪怕是重启都会导致名称改变

核心问题在于 enp2s0 这种命名规则本身是不稳定的，比如你插入一张新的网卡此时 enp2s0 可能指向新的网卡而原本的网卡则漂移到 enp3s0 去了。这个规则的设计者认为：

1. 保证网卡名称不冲突比保证网卡名称的稳定性更重要
2. 更短的网卡名称比 mac 地址更便于维护
3. 设计一套自动记忆 mac 地址和网卡名称的机制会增加系统复杂度且没必要
4. 再添加一个手动配置网卡地址的机制让开发者可以固定名称
5. 再添加一个再散列机制，保证自动网卡名称和用户固定的名称不冲突

这个设计是他们认为折中之后最好维护并且对绝大部分人用户最友好或者说最可以接受的机制，而在这套机制下新手用户注定会在第一次增减 PCIe 设备时遇到断网的问题，然后祝这个机制的开发者全家人身体健康之后去固定网卡地址。

说实话，如果他们把这套机制命名为 “网卡自动命名机制” 的话我还可以接受，但他们却将这套机制命名为：

[可预测网卡名称]

我知道这个机制的存在是必要的是有意义的，但是他避免不了

[新手运维第一次增减 PCIe 设备后断网]
的问题，如果这个设计是无可奈何的话那么有人骂他这套设计不好一样也是无可奈何的

其实可以避免，因为这套机制有根据 MAC 自动命名的特性，但是需要用户主动启用

用户如何在不知道这套机制存在的情况下避免这个问题，这才是槽点

只能说是不得已的方案。通过 MAC 重命名也有无法避免的问题，比方说根据 SR-IOV 虚拟化出来的网卡 VF 没有永久的 MAC 地址，通常是 post-up 后手动设置，根本没有可能根据 MAC 重命名。