请不要把任何和邀请码有关的内容发到 NAS 节点。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
前几天发了个“帖子：关于 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 等系统才能用。
多少有点发牢骚了，大家就当看个热闹了。
 |
1
LokiSharp 2 天前
我是匹配 pci Path 或者 mac 地址之后自己取别名的
|
 |
2
OneLiteCore OP @LokiSharp 最后也只能这么做，但这个设计真的算不上“用户友好”
|
 |
3
Kirkcong 2 天前  2
网卡名称由于新设备插入而变更是常规操作，也很合理。如果需要固定某一设备的名称，请使用 udev 来修改，我司所有在用的网口都使用 udev 来固定的。
|
 |
4
RanKaede 2 天前
不动 pcie 设备位置网卡名字也会变的么？
其实前几年一直用的 ethx 换了新设备变成了 enpxsx 还觉得挺奇怪，就查了一下原来跟 PCI 接口位置有关 |
 |
5
user100saysth 2 天前
我也遇到过，哈哈哈 加了个硬盘，然后 pve 断网了
|
 |
7
coldle 2 天前
pve 日常，有次有个 nixos 机器重启一下发现 ip 变了，定位一通发现网卡名已经不是配置里指定的那个了。。
|
|
8
OneLiteCore OP @RanKaede 插拔 PCIe 设备会导致网卡名称变化，ethx 是旧版本的网卡名称 enpxsx 则是新特性，关键词可以去搜索 Predictable network interface names 相关资料。
顺带吐槽一下虽然这个机制翻译过来叫“可预测网络接口名称”，但实际使用中基本和“预测”这俩字无关。 |
 |
9
totoro625 2 天前
@OneLiteCore #8 我还遇到过改直通导致网卡名称变化
|
 |
10
ragnaroks 2 天前
应该是 PVE 专属 BUG ？
debian 13 未复现，已有 enp4s0 （ 10G ）的情况下加了一张是 enp4s1 （ 1G ），交换两张卡位置后也确实变成了 enp4s0 （ 1G ）和 enp4s1 （ 10G ） |
 |
11
poxiaogg 2 天前
好像新版本有改进这个网卡名称的问题
|
|
12
OneLiteCore OP @ragnaroks 可以用 Predictable network interface names 作为关键字搜索，就目前我找到的资料都是把这个当成一个 feature 或者新机制的，而非当成一个 bug
|
|
13
OneLiteCore OP @poxiaogg 我使用的是 PVE 9.0 按理说已经是最新的系统了
|
 |
14
Mlfamlfy 2 天前
我上周加了个双口网卡导致管理口从 enp3s0 变成 enp9s0 ，新网卡上一个口变成了 enp3s0 ，直接导致 PVE 宿主机连不上
|
 |
15
msg7086 2 天前
直接使用可预测网卡名称会导致网卡名称不可预测。
解决方法也很简单，用 PVE 常年以来都有的固定网卡名称功能就行了。 proxmox-network-interface-pinning generate proxmox-network-interface-pinning generate --interface enp4s0 --target-name nic10g1 然后 PVE 会创建关联文件，通过 MAC 映射网卡到固定名称。 |
 |
17
AkinoKaedeChan 1 天前 via Android
这个应该是消费级主板才有的问题，因为可预测名称是按 PCI 编号来的，很多消费级主板新增减少 PCIe 设备会改变编号，服务器主板应该是真的可预测
|
|
18
OneLiteCore OP @AkinoKaedeChan 作为一个普通的软件开发者觉得这块明显设计有问题。
你看上面有些应该是有运维经验的大佬都提到他们公司是使用了 udev 来固定网卡名称，或者使用 pve 自带的功能来固定网卡名称，这说明固定网卡名称确实是一种更常见的需求，同时企业级的设备也需要固定网卡名称。 我的想法是，如果一个功能的最终下场是让大家不要使用这个功能，那么这个功能一开始就不应该存在或者应该有更好的设计。 |
|
19
AkinoKaedeChan 1 天前
@OneLiteCore 这个特性当然是有意义的，以前哪怕是重启都会导致名称改变
|
|
20
OneLiteCore OP @AkinoKaedeChan 核心问题在于 enp2s0 这种命名规则本身是不稳定的，比如你插入一张新的网卡此时 enp2s0 可能指向新的网卡而原本的网卡则漂移到 enp3s0 去了。这个规则的设计者认为：
1. 保证网卡名称不冲突比保证网卡名称的稳定性更重要 2. 更短的网卡名称比 mac 地址更便于维护 3. 设计一套自动记忆 mac 地址和网卡名称的机制会增加系统复杂度且没必要 4. 再添加一个手动配置网卡地址的机制让开发者可以固定名称 5. 再添加一个再散列机制，保证自动网卡名称和用户固定的名称不冲突 这个设计是他们认为折中之后最好维护并且对绝大部分人用户最友好或者说最可以接受的机制，而在这套机制下新手用户注定会在第一次增减 PCIe 设备时遇到断网的问题，然后祝这个机制的开发者全家人身体健康之后去固定网卡地址。 说实话，如果他们把这套机制命名为 “网卡自动命名机制” 的话我还可以接受，但他们却将这套机制命名为： [可预测网卡名称] |
|
21
OneLiteCore OP @AkinoKaedeChan 我知道这个机制的存在是必要的是有意义的，但是他避免不了
[新手运维第一次增减 PCIe 设备后断网] 的问题，如果这个设计是无可奈何的话那么有人骂他这套设计不好一样也是无可奈何的 |
|
22
AkinoKaedeChan 1 天前 via Android
@OneLiteCore 其实可以避免，因为这套机制有根据 MAC 自动命名的特性，但是需要用户主动启用
|
|
23
OneLiteCore OP @AkinoKaedeChan 用户如何在不知道这套机制存在的情况下避免这个问题，这才是槽点
|
|
24
AkinoKaedeChan 1 天前 via Android
只能说是不得已的方案。通过 MAC 重命名也有无法避免的问题，比方说根据 SR-IOV 虚拟化出来的网卡 VF 没有永久的 MAC 地址，通常是 post-up 后手动设置，根本没有可能根据 MAC 重命名。
|
|
25
msg7086 1 天前
@OneLiteCore #20
可预测网卡名称解决的是重启时名称改变的问题。 比如你有两块网卡，可能一次启动的时候 eth0 是第一块，eth1 是第二块，下次启动的时候 eth0 是第二块，eth1 是第一块。打开可预测网卡名称以后，至少你遇到断网问题是下一次增减 PCIe 设备的时候，而不是下次重启的时候…… 另外可预测网卡名称也有其他绑定的名称。比如我 PVE 上的网卡名称类似这样： #ip link 2: eno1: altname enp5s0f0 altname enx50106f45a51a 3: eno2: altname enp5s0f1 altname enx50106f45a51b 4: eno49: altname enp12s0f0 altname enx4cb9018861dc 6: ens2: altname enp9s0 altname enxe11d2d153860 普通人如果你只有一个网卡，那直接 eno1 就完事了。 你如果觉得 enp 和 eno 编号都不舒服，那也可以用 enx 来通过 mac 绑定。 |
|
26
OneLiteCore OP @msg7086 我之后查阅了资料了解到这个机制确实比 ethX 规则更进步的地方也知道有办法自己固定网卡名称。
槽点在于这个设计下会出现 “我就插了一块新的 SSD 怎么就忽然断网了？” 的情况，对于没那么熟悉 Linux 设计的人而言这个设计完全就是 “不可预测的”，而他们将这套机制命名为 “可预测网卡名称”… 如果他们用 “网卡自动命名机制” 这个名字我反而觉得可以理解是不得已而为之 |
|
27
msg7086 20 小时 15 分钟前
@OneLiteCore
实际系统运行环境下是没有万金油的。要是你说按照 MAC 绑定好，那遇上网卡坏了，你买了块新卡换上，结果还是会断网，因为新卡在同一插槽，但 MAC 不同。这时候原本的按插槽匹配就很有用了。 反正不管你怎么设计，总会有一群人遇到网卡对不上的问题，无非是这一群人或者那一群人的区别而已。 |
|
28
OneLiteCore OP @msg7086 我能接受网卡损坏导致按照 Mac 的配置无法上网，也能接受用新的网卡刚插上去没配置无法上网，因为这些和网络是相关的，但 “插一块 SSD 导致断网” 则是反直觉且不可预测的，只不过这个是各种方案折中妥协后必然会出现的一个潜在问题而我刚好遇到了而已。
只能说就很黑色幽默。 |
Select Language