PVE直通万兆网卡高负载下载时宿主机直接死机失联，该怎么抓取崩溃日志？

在玩 Homelab 或者企业私有云时，PVE（Proxmox VE）直通万兆网卡（如 Intel X520/X540、Mellanox ConnectX-3/4、Aquantia 等）是压榨网络性能的常见操作。

然而，不少人会遇到一个极其崩溃的现象：平时轻载运行一切正常，一旦开启大流量下载（如 PT 满速、本地 NAS 之间大文件对拷），万兆网卡跑满几秒到几分钟后，宿主机突然彻底失联。

此时，不仅虚拟机断网，PVE 的 Web 登录不进，SSH 连不上，甚至连宿主机本地接的显示器也是黑屏或画面冻结。强行按下电源键重启后，翻遍 /var/log/syslog 或 journalctl，却发现故障发生的时间点一片空白，没有任何有用日志。

为什么会这样？因为在高负载导致内核恐慌（Kernel Panic）或硬件保护（如 PCIe 报错引发的硬锁死）时，系统 CPU 已经停止响应，或者磁盘 I/O 线程已被锁死，崩溃瞬间的信息根本来不及写入硬盘。

要抓取这种“瞬时死机”的现场日志，我们需要绕过常规的本地磁盘写入机制。以下是几种最有效的实操抓取手段，按操作难度由易到难排列：

方案一：调整 Systemd-journald 机制，强制实时刷盘（最简单，但成功率看运气）

默认情况下，Linux 的 systemd-journald 为了保护硬盘（尤其是装在 SSD/闪存上的系统），会将日志缓存在内存中，隔一段时间（通常是5秒）或达到一定量才刷入硬盘。死机时，这关键的5秒日志就丢了。

我们可以通过修改配置，让日志“一有就写”，尽量在死机前的一瞬间把遗言留在硬盘里。

修改 journald 配置文件：
```
nano /etc/systemd/journald.conf
```
找到或修改以下参数：
```
[Journal]
Storage=persistent
SyncIntervalSec=0
```
将 SyncIntervalSec 设为 0 表示禁用延迟写入，所有日志实时刷写进盘。
保存退出，重启日志服务：
```
systemctl restart systemd-journald
```
测试复现：去让网卡高负载，直到死机。强制重启后，使用以下命令查看最后一次死机前的日志：
```
journalctl -b -1 -r
```
(寻找是否有 PCIe Bus Error、DMAR: [DMA Read]、ixgbe / mlx4 相关的 Reset adapter 或 tx unit hang 字样。)

方案二：配置 Netconsole（网络控制台），将日志实时发往另一台电脑（最推荐）

如果死机是由 PCIe 严重错误引起的，整机总线可能会瞬间锁死，方案一的磁盘写入依然会失败。此时，Netconsole 是最好的解决办法。

Netconsole 是 Linux 内核的一个模块，它可以在不经过完整网络协议栈、甚至在内核崩溃的边缘，直接将 dmesg（内核日志）打包成 UDP 数据包，通过网卡（注意：必须使用 PVE 宿主机上未直通的、工作正常的管理网口）发射给局域网内的另一台电脑。

1. 在接收端（另一台电脑）准备接收

接收端可以是局域网内的任何一台 Linux/Windows/Mac 电脑。假设接收端 IP 为 192.168.1.100。

如果是 Linux/Mac 接收端，直接运行 nc（netcat）监听端口：
```
nc -u -l -p 6666
```
如果是 Windows 接收端，可以使用 Wireshark 抓取 UDP 6666 端口的包，或者使用类似 TCPUDPDebug 的工具监听 UDP 6666。

2. 在 PVE 宿主机（发送端）配置 Netconsole

假设 PVE 上未直通的管理网卡接口名为 enp3s0，PVE 的 IP 是 192.168.1.10，网关/交换机 MAC 地址为 xx:xx:xx:xx:xx:xx（可以通过 arp -a 查到）。

临时加载并启动 netconsole 模块：

modprobe netconsole netconsole=6666@192.168.1.10/enp3s0,6666@192.168.1.100/xx:xx:xx:xx:xx:xx

格式解释：netconsole=监听端口@本机IP/网卡名,接收端口@目标IP/目标MAC

为了验证是否成功，可以在 PVE 上手动触发一条内核日志：

echo "K" > /proc/sysrq-trigger

此时，你的接收端屏幕上应该会瞬间弹出一行类似 SysRq : Keyboard Action 的日志。

3. 复现故障

保持接收端监听，去压测万兆网卡。在 PVE 挂掉的那一瞬间，盯着接收端的屏幕，内核最后的挣扎（通常是 panic、BUG: unable to handle kernel paging request 或 IOMMU 报错）会被完整记录下来。

方案三：利用 IPMI / IKVM 挂载虚拟串口（适合企业级服务器）

如果你的 PVE 运行在戴尔（iDRAC）、惠普（iLO）、超微（IPMI）或带有 PiKVM 的自建平台上，你可以利用**串口重定向（Serial-over-LAN / SOL）**来抓取最底层的日志。

通常，即使系统图形界面卡死，串口控制台（TTY）依然会输出最底层的 Kernel Panic 信息，而且许多服务器带外管理卡提供了“崩溃截屏”或“系统事件日志（SEL）”。

在 PVE 的 /etc/default/grub 中，为内核添加串口控制台参数：
```
GRUB_CMDLINE_LINUX_DEFAULT="quiet console=tty0 console=ttyS1,115200"
```
(注：ttyS1 对应服务器主板的虚拟串口，具体编号取决于主板说明书，通常是 ttyS0 或 ttyS1)
更新 grub：
```
update-grub
```
重启 PVE，并在另一台电脑上通过 IPMI 工具连接到该虚拟串口，开启日志记录功能（Log to File），然后复现故障。

方案四：开启 Magic SysRq（魔法钥匙），在死机时强行写入

有时候系统并不是真的“硬死机”，而是由于用户态网络管理程序崩溃导致的假死。此时内核其实还在运行，你可以通过 Magic SysRq 键向内核直接发送指令，强行刷写磁盘或导出当前的进程调用栈。

确保 PVE 开启了 SysRq 支持：
```
sysctl -w kernel.sysrq=1
```
当高负载下载失联发生时，如果宿主机接了物理键盘：
- 依次按下 Alt + SysRq (PrintScreen) + t（该组合键会将当前所有进程的调用栈和寄存器状态输出到控制台/日志中）。
- 依次按下 Alt + SysRq + s（强制同步所有挂载的文件系统，将未写入的日志刷入磁盘）。
- 依次按下 Alt + SysRq + b（安全地立即重启系统）。
重启后去查看 /var/log/syslog，寻找刚才导出的调用栈。

抓到日志后，如何定位常见诱因？

万兆网卡高负载死机，抓到的日志大概率会指向以下几个方向。你可以根据日志特征或提前排查以下硬伤：

1. IOMMU 与 DMA 冲突（最常见）

日志特征：DMAR: [DMA Read] Request device [xx:xx.x] fault addr... 或 IOMMU: AMD-Vi: Event logged [IO_PAGE_FAULT...]
原因：万兆网卡在高负载下发起极其频繁的 DMA（直接内存访问）请求，而 PVE 的 IOMMU（VT-d/AMD-Vi）在地址转换时出错或被拦截。
解决方法：
- 在 GRUB 中尝试开启 iommu=pt（Pass-Through 模式，让直通设备在不使用时绕过 IOMMU 转换）。
- 或者是软硬件不兼容，尝试关闭 PCIe 设备的 ACS 支持，或更换 PCIe 插槽（避免和显卡或其他高速设备共享同一组 CPU 直通通道）。

2. MSI-X / 中断风暴（Interrupt Storm）

日志特征：irq xx: nobody cared，或者 tx unit hang。
原因：网卡产生的中断信号（MSI/MSI-X）过多，CPU 核心无法及时处理，导致 CPU 陷入中断处理死循环，从而引发“软锁死（Soft Lockup）”。
解决方法：
- 检查 PVE 宿主机的 CPU 溫度，过热降频会导致处理中断能力断崖式下跌。
- 在 PVE 中关闭网卡的 ASPM（PCIe 活动状态电源管理），防止网卡在高负载和低功耗状态切换时中断丢失。

3. 网卡硬件过热保护（物理硬伤）

现象：没有任何日志，系统瞬间断电、或者网卡灯灭。
原因：Intel X520、X540、Broadcom 等早期的万兆电口网卡发热量极大（高达 10W-15W）。在千兆宽带满速或内网万兆满载时，芯片温度会瞬间飙升到 90℃ 以上。如果机箱内没有强风道，网卡芯片触发热保护会直接锁死 PCIe 总线，导致整机瞬间硬挂。
解决方法：用手摸一下网卡散热片。如果是烫得无法停指，请立刻给网卡加装 4010 小风扇，或者改善机箱风道。这能解决 80% 莫名其妙的万兆失联故障。