麒麟系统ARM64虚拟机网络故障分层排查指南

麒麟系统装在ARM64虚拟机里界面能起来、桌面也正常唯独网络那一栏永远是个红叉或者灰点——这个场景我遇到过不止一次帮同事看、帮项目现场看前前后后踩了七八回坑每次的表面现象都差不多真正的病因却分布在完全不同的层。有人以为是虚拟机软件没配好有人怀疑是驱动缺了还有人直接重装系统结果重装完照样没网。这篇就把这套问题的排查路径完整摊开讲从怎么判断是网卡没被识别还是网卡识别了但拿不到地址到ARM64虚拟化环境下virtio网卡的特殊性再到NetworkManager接管权、DHCP客户端、路由DNS、MTU与校验和这些容易忽略的边角。适合正在用麒麟系统做ARM64虚拟化验证的开发、运维和适配人员看也适合刚接触国产化环境、被这个问题卡住半天的新手——照着走一遍基本能定位到自己那一层。1. 先给网络故障分层从网卡不存在到能ping通却打不开页面网络不通这四个字太笼统了不同层级的表现看起来一样排查入口却完全不同。我习惯在动手改任何配置之前先用两三条命令把故障归到某一个层避免在错误的层上瞎折腾。这一步花不了五分钟但能省掉后面一个小时。1.1 三类现象对应三个完全不同的排查方向第一类是系统里根本看不到网卡设备。执行ip link只看到lo一个回环接口连eth0、ens33这种名字都没有。这种情况问题在虚拟化层或驱动层跟系统内部的网络配置一点关系都没有你去改ifcfg文件、去重启 NetworkManager 全是白费力气。第二类是网卡在但没有IP地址。ip addr能看到enp0s1之类的接口状态是UP或者DOWN但inet那一行是空的。这说明驱动和硬件识别都没问题卡在了地址获取环节——要么 DHCP 没跑起来要么 NetworkManager 没接管这个设备要么虚拟机的网络模式压根没提供 DHCP 服务。第三类是地址有了但访问不了外部。ip addr显示192.168.122.50/24ping网关通ping外网IP通但浏览器打不开网页或者ping域名直接报未知的主机。这时候问题在路由、DNS 或者上层协议网卡和地址都是好的。这三类的排查路径几乎没有重叠。我见过太多人一上来就systemctl restart NetworkManager重启十遍也没用因为他的问题其实是第一类——虚拟机根本没把网卡设备透给系统。1.2 一条组合命令完成初步分层不想记太多命令的话开局先跑这一条ip -br link; echo ---; ip -br addr; echo ---; nmcli device statusip -br是 brief 模式输出紧凑一眼能看全。三段输出分别回答三个问题有哪些链路层设备、每个设备有没有IP、NetworkManager 怎么看待这些设备。判断逻辑很直接输出特征故障层级下一步方向只有lo无其他接口设备未识别查虚拟机网卡型号、查内核驱动有接口但nmcli显示unmanaged管理权未接管查 NetworkManager 配置文件有接口、nmcli显示disconnected未激活或无DHCP查虚拟机网络模式、手动激活有接口有IPnmcli显示connected上层配置问题查路由、DNS、防火墙nmcli device status这一列特别关键。很多人只看ip addr有地址就以为万事大吉实际上地址可能是手工配的临时地址NetworkManager 并没有接管重启就没了而且 DNS 也不会自动写入。我印象比较深的一次是某项目现场同事反馈麒麟虚拟机网络时好时坏。跑完上面这条命令发现网卡处于unmanaged状态但系统里残留了一个手工写的静态地址所以有时候能通。这种半吊子状态最坑人因为现象不稳定容易误判成网络抖动。2. ARM64虚拟化环境里网卡到底有没有被内核认出来ARM64 平台和 x86 在设备枚举上有一处根本差异x86 靠 PCI 总线和 ACPI 枚举设备ARM64 除了 PCIe 之外还可能是设备树Device Tree或者 ACPI 的混合模式。虚拟化软件如果没把这一层配好网卡设备就压根不会出现在系统里表现为第一类故障。2.1 从内核日志确认virtio-net驱动是否加载ARM64 虚拟机里最推荐的网卡型号是virtio-net它由半虚拟化驱动配合性能好、兼容性稳。先确认驱动模块在不在lsmod | grep -i virtio正常应该能看到virtio_net、virtio_pci、virtio_ring、virtio这一组。如果virtio_net缺席说明模块没加载或者内核里没编进去。再往下挖一层看内核在启动时有没有发现设备dmesg | grep -iE virtio|eth|net健康的输出里会有一串类似virtio_net virtio0 enp0s1: renamed from eth0的记录。看到renamed from eth0就说明设备已经认到了只是被 udev 改了名字这属于正常现象。如果dmesg里压根没有任何 virtio 网络设备的痕迹那问题在更下面——虚拟机的 XML 配置或者图形界面里网卡设备可能根本没挂上去。lspci在 ARM64 上同样可用前提是虚拟化平台暴露了 PCIe 总线lspci -nn | grep -i -E ethernet|network能列出设备就说明 PCIe 枚举成功列不出来就得回头查虚拟机配置。这里有个细节部分 ARM64 虚拟化方案尤其是一些轻量级方案默认给的是e1000这种 x86 时代的模拟网卡在 ARM64 上要么不被支持要么驱动缺失表现就是设备列表空空如也。把网卡型号改成virtio基本能一次解决。2.2 网卡命名规则变化带来的认知偏差麒麟系统用的是 systemd 的可预测网卡命名规则网卡名可能是enp0s1、ens3、enx加 MAC 地址不再是你熟悉的eth0。这件事本身不构成故障但会让排查走偏——很多人ifconfig没输出就断定没网卡其实ifconfig在新系统里可能压根没装得用ip addr。ifconfig属于 net-tools 包麒麟的某些最小化安装镜像默认不带。我遇到过同事在终端敲ifconfig报 command not found转头就说系统没网卡其实ip addr一跑全都在。如果你确实想让网卡名回到eth0这种老样子比如有脚本依赖这个名字可以在内核启动参数里加net.ifnames0 biosdevname0然后重建 initramfs。不过我的建议是别改顺着新命名规则走脚本里用ip -o link动态取名字更稳妥。改命名规则这事改完当时能用下次内核升级或者换虚拟机又得重新折腾得不偿失。2.3 设备树与ACPI路径下的枚举差异这一点偏底层但值得说清楚因为它是 ARM64 特有的坑。ARM64 虚拟机启动时固件通常是 UEFI/EDK2会向内核提供一份硬件描述形式可能是 ACPI 表也可能是设备树。如果虚拟机配置里既没提供 ACPI设备树又写得残缺内核就枚举不到 PCIe 上的网卡设备。判断方法是看内核启动日志里关于 ACPI 的部分dmesg | grep -i ACPI:.*PCI或者直接看/proc/device-tree目录存不存在ls /proc/device-tree 2/dev/null | head有内容说明走的是设备树路径。这种情况下如果网卡没出现多半是虚拟机配置文件里device tree或者ACPI开关没开。主流虚拟化平台默认都会配好只有自己手写 QEMU 命令行的时候容易漏。我踩过一次手工拼qemu-system-aarch64命令启动参数里忘了加-machine virt结果系统能起来但所有 PCIe 设备都没有网卡自然也没有。加上这个参数就好了。所以如果你是自己写启动脚本的先检查 machine 类型。3. NetworkManager与旧式网络脚本抢方向盘地址为什么拿不到设备认出来了网卡也在但就是拿不到地址——这是最高频的一类。麒麟系统内部同时存在多套网络管理机制NetworkManager、传统的 network-scripts、systemd-networkd甚至 cloud-init 也会插一手。几套机制互相覆盖配置结果就是谁都没能把地址配上。3.1 查看设备是否处于unmanaged状态nmcli device status输出里如果STATE列是unmanaged说明 NetworkManager 明确拒绝管理这个设备。原因通常藏在配置文件里grep -r managed /etc/NetworkManager/NetworkManager.conf /etc/NetworkManager/conf.d/ 2/dev/null如果看到managedfalse那就是全局关闭了设备管理。改成true或者直接删掉这一行然后重启服务systemctl restart NetworkManager nmcli device status还有一种情况是某个设备被单独排除。/etc/NetworkManager/conf.d/下可能有类似这样的片段[keyfile] unmanaged-devicesinterface-name:enp0s1这种配置一般是为了让某个网卡交给别的工具管理比如网桥场景但如果是历史遗留就会导致新装的虚拟机网卡一直被晾着。unmanaged状态特别容易误判。因为设备本身是好的链路层也是 UP 的只是没人给它配地址。你手工ip addr add加一个地址也能通但重启就没了而且 DNS 不会配。所以看到unmanaged一定要去配置里找原因别用手工命令糊弄过去。3.2 DHCP客户端缺失或不工作的典型表现设备被接管了状态显示disconnected或者一直在connecting循环多半是 DHCP 拿不到租约。先看虚拟机侧的网络模式NAT 模式一般自带 DHCP 服务桥接模式则要求外部网络里有 DHCP 服务器仅主机模式需要虚拟化平台自己起 DHCP。确认虚拟机侧没问题之后再看系统侧。麒麟系统默认用 NetworkManager 内置的 DHCP 客户端但有些精简镜像里dhclient或dhcpcd包没装会报类似dhcp4 (enp0s1): activation: failed for connection的错误。查看方式journalctl -u NetworkManager -n 100 --no-pager日志里如果出现DHCP client failed或者dhcp4: request timed out基本就是这一层。补齐客户端rpm -q dhclient || yum install -y dhclient装完再激活连接nmcli connection up 有线连接 1这里有个小坑连接名称可能不是中文的有线连接 1用nmcli connection show看准确的 NAME 列。中文名称在命令行里需要加引号实在嫌麻烦可以重命名成英文nmcli connection modify 有线连接 1 connection.id eth-dhcp3.3 手工配静态地址一份可以直接抄的完整流程DHCP 这条路实在走不通或者虚拟机所在网络本来就没有 DHCP那就配静态地址。我倾向于用nmcli而不是直接改文件因为nmcli写的是 keyfile 格式NetworkManager 会正确加载DNS 也会一起管好。以 NAT 网络192.168.122.0/24、网关192.168.122.1为例nmcli connection add type ethernet ifname enp0s1 con-name eth-static \ ipv4.method manual \ ipv4.addresses 192.168.122.50/24 \ ipv4.gateway 192.168.122.1 \ ipv4.dns 192.168.122.1,223.5.5.5几条要点ifname必须和ip link里看到的接口名完全一致写错了连不上。ipv4.method manual少了这一项地址配了也会被 DHCP 覆盖。DNS 用逗号分隔第一个是内网 DNS第二个是公网兜底。配完立刻nmcli connection up eth-static再用ip route确认默认路由出来了。验证三步走ip route show default # 应该有 default via 192.168.122.1 ping -c 3 192.168.122.1 # 通网关 ping -c 3 223.5.5.5 # 通外网IP三层都通网络层就打通了。剩下的 DNS 解析和上层协议另说。4. 地址有了却不通路由、DNS、MTU这三关逐一过到这一步ip addr里地址有了nmcli显示connected但用户还是说上不了网。这时候问题往往藏在三个地方默认路由缺失、DNS 解析失败、MTU 不匹配。这三关的症状有微妙差别分清楚能少走很多弯路。4.1 默认网关缺失与路由表异常看路由表ip route健康的输出里应该有一行default via 192.168.122.1 dev enp0s1。没有这一行说明网关没配上表现是能 ping 同网段设备、但访问任何外网地址都超时。这种情况在用ip addr add手工配地址时特别常见——ip addr只管地址不管路由。正确做法是配完地址再补一条ip route add default via 192.168.122.1 dev enp0s1不过手工路由重启就丢长期方案还是回到nmcli的ipv4.gateway参数。还有一种更隐蔽的路由表里有默认路由但指向了错误的接口。比如系统里同时存在两张网卡一张连 NAT 一张连仅主机网络默认路由指到了仅主机那张上外网自然不通。用ip route get 223.5.5.5可以精确看到某个目标地址会走哪个接口ip route get 223.5.5.5输出里的dev字段就是实际出口。如果和目标预期不符调整路由优先级或者删掉多余的路由。多网卡场景下ip route会显示多条default靠metric值决定优先级数值小的优先。调整方式是在nmcli里设ipv4.route-metric。4.2 DNS解析失败的隐蔽原因能 ping 通外网 IP但ping www.example.com报未知的主机那就是 DNS 层。先看当前用的 DNScat /etc/resolv.conf麒麟系统里这个文件可能是软链接指向/run/NetworkManager/resolv.conf或者/run/systemd/resolve/resolv.conf具体指向哪个取决于哪套服务在管。如果里面有nameserver 127.0.0.53说明是 systemd-resolved 接管了 DNS得再查一层resolvectl status如果 NetworkManager 和 systemd-resolved 同时在跑很容易互相覆盖导致/etc/resolv.conf里的内容一会儿有一会儿没有。我的处理方式是二选一要么停掉 systemd-resolved让 NetworkManager 直接写文件要么让 NetworkManager 把 DNS 推给 systemd-resolved。前者简单粗暴systemctl disable --now systemd-resolved rm -f /etc/resolv.conf systemctl restart NetworkManager另一种常见原因是/etc/resolv.conf被设成了不可修改chattr iNetworkManager 写不进去。用lsattr /etc/resolv.conf看一下如果有i属性chattr -i /etc/resolv.conf这个属性一般是安全加固脚本加的加完就忘了后面改 DNS 一直不生效排查起来很费时间。4.3 虚拟化环境特有的MTU与校验和问题这一类属于能 ping 通小包、大包就卡死的典型症状。表现是ping网关正常ping外网IP也正常但一打开网页、一拉大文件就超时或者卡在加载中。原因通常是 MTU 不匹配或者校验和卸载在虚拟化环境里出了问题。MTU 排查ip link show enp0s1 | grep mtu ping -M do -s 1472 223.5.5.5-M do表示禁止分片-s 1472加上 IP 头 20 字节和 ICMP 头 8 字节正好是 1500。如果这个包通不了但-s 1400能通说明链路上实际可用的 MTU 小于 1500常见于叠加了隧道或者多层虚拟化的环境。调整nmcli connection modify eth-static 802-3-ethernet.mtu 1400 nmcli connection up eth-static校验和问题则表现为抓包看数据都发出去了但对端收不到或者校验失败。检查卸载状态ethtool -k enp0s1 | grep -E tx-checksum|rx-checksum在 virtio 网卡上校验和卸载一般是开启的正常不需要动。但在一些嵌套虚拟化或者老旧虚拟化平台上这个特性会导致丢包。临时关闭验证ethtool -K enp0s1 tx off rx off如果关掉之后正常了说明就是这个问题可以写进 NetworkManager 的 dispatcher 脚本里持久化或者干脆换一个虚拟化平台的版本。5. 虚拟机网络模式选型NAT、桥接、仅主机在ARM64上的差异很多连不上网的问题根子不在系统里而在虚拟机网络模式选错了或者模式对了但配套服务没起来。选型这一步做对后面能省掉一半的排查工作。5.1 三种模式的适用边界与配置要点模式地址来源外网可达宿主机可达外部设备可达虚拟机适用场景NAT虚拟化平台内置DHCP是是否需端口转发单机验证、日常开发桥接外部网络DHCP或静态是是是需要被外部访问的服务仅主机虚拟化平台内置DHCP否是否隔离测试、多机组网NAT 模式最省事虚拟机启动就能拿到地址网关一般是平台分配的固定地址。以常见的 libvirt 默认网络为例网段是192.168.122.0/24网关.1DHCP 范围从.2开始。如果nmcli一直拿不到地址先确认宿主机上这套 NAT 网络是不是启动了virsh net-list --all状态不是active的话virsh net-start default virsh net-autostart default桥接模式在 ARM64 上要特别注意物理网卡是否支持。有些平台在 ARM64 上创建桥接时用的是虚拟网桥而不是真的把物理网卡桥出去导致虚拟机能拿到地址但访问不了外部网络。验证方法是看虚拟机的 MAC 地址是否出现在外部网络的 ARP 表里。仅主机模式最容易踩的坑是它默认不带 NAT 转发虚拟机之间能通、宿主机能通但出不去。如果只是做几台虚拟机之间的组网测试这个模式最干净如果误以为它能上网就会一直困惑为什么网关能 ping 通但外网不通。5.2 麒麟系统自带安全机制对网络行为的干扰麒麟系统带了一些安全增强组件默认状态下可能会对网络行为做一些限制。这类限制平时不显山露水但在虚拟机环境里排查网络问题时容易被误认为是配置错误。排查思路是先确认这些组件的当前状态再判断是否与故障相关。如果系统里有对应的状态查询命令先跑一遍看输出。如果确实处于启用状态且策略较严格可以临时调整到宽松模式做一次对照测试——如果网络立刻恢复就说明是策略在起作用这时候应该针对性放行而不是长期关闭。需要强调的是不要一上来就关安全组件。先做对照测试确认因果关系再有针对性地加白名单这是更负责任的做法。我见过有人为了快速解决把安全策略全关了结果系统上线后出了别的问题回头一查才发现当初的网络故障跟安全策略压根没关系白关了。另一个容易忽略的点是防火墙。麒麟系统默认可能启用 firewalldsystemctl status firewalld看状态。如果是active先看规则firewall-cmd --list-all出站流量默认是放行的所以单纯上不了网很少是防火墙导致的。但如果是在做端口转发、NAT 共享这类场景防火墙就需要显式放行。诊断的时候可以临时停掉做对照systemctl stop firewalld确认恢复后记得重新启动并且用firewall-cmd --permanent加上正确的规则而不是长期关闭。6. 一次完整排障的链路复盘从现象到修复的每一跳前面讲的都是分层的知识点这一节把一次真实的排查过程完整走一遍让整个链路串起来。你会发现真正花时间的不是修而是定位。6.1 故障现象与最初的错误假设场景是这样某项目现场一台 ARM64 虚拟机装好麒麟系统桌面正常任务栏网络图标显示未连接。同事的第一反应是虚拟机网络没配于是在虚拟化平台上把网络模式从 NAT 改成桥接又改回 NAT来回折腾了半小时没有任何变化。第二个假设是系统没装网卡驱动准备重新装系统。这时候我接手看了一下先跑ip -br link输出是lo UNKNOWN 00:00:00:00:00:00 enp0s1 UP 52:54:00:xx:xx:xx网卡明明在而且链路是 UP 的。所以第一个假设和第二假设都不成立问题在地址获取这一层。这一条命令就把排查范围从整个系统缩小到了NetworkManager 和 DHCP。6.2 逐层验证与最终定位接着跑nmcli device statusDEVICE TYPE STATE CONNECTION enp0s1 ethernet disconnected -- lo loopback unmanaged --disconnected说明设备被 NetworkManager 识别了但没有激活任何连接配置。再看有没有现成的连接nmcli connection show输出是空的一个连接配置都没有。这就解释了为什么disconnected——系统里压根没有为这张网卡创建过连接配置文件。正常情况下NetworkManager 检测到新网卡会自动创建一个 DHCP 连接。自动创建没发生说明要么是被配置禁用了要么是创建失败了。查配置grep -r no-auto-default /etc/NetworkManager/果然/etc/NetworkManager/NetworkManager.conf里有这么一行[main] no-auto-default*这行的意思是任何设备都不要自动创建默认连接。这个配置一般是批量部署时为了统一管理而加的但如果部署脚本没配套地把连接配置写进去新机器就成了有网卡没配置的状态。修复很直接两种方式任选删掉这一行后重启服务让它自动创建或者手工创建一个 DHCP 连接。我选了后者更可控nmcli connection add type ethernet ifname enp0s1 con-name eth-dhcp ipv4.method auto nmcli connection up eth-dhcp执行完再ip addr show enp0s1地址192.168.122.87/24出来了网关和 DNS 也一起配好了。ping网关通ping外网通浏览器正常打开。整个过程从接手到修好不到十分钟其中八分钟在确认现象改配置只花了三十秒。6.3 复盘时容易被忽略的三个细节第一个细节是不要跳过现象确认直接动手。如果一开始就去重装系统问题依然存在因为no-auto-default*这个配置是镜像自带的重装还是同样的镜像还是同样的配置还是同样的结果。很多人陷入重装—不通—再重装的循环根本原因就在这里。第二个细节是**nmcli device status的 STATE 列信息量远大于ip addr**。ip addr只能告诉你有没有地址nmcli能告诉你 NetworkManager 对这个设备的态度。unmanaged、disconnected、connecting、connected四种状态对应四条完全不同的排查路径这一步判断对了后面基本是照着走。第三个细节是配置文件里的批量部署痕迹值得优先怀疑。像no-auto-default*、unmanaged-devices...、managedfalse这类配置几乎都是部署脚本加进去的目的是统一管理。但部署脚本往往是一次性的配置留在镜像里后面的人接手就会莫名其妙。我现在的习惯是遇到任何系统行为不符合默认预期的情况先去/etc/NetworkManager/conf.d/和主配置里翻一遍十有八九能找到人为干预的痕迹。最后分享一个我常用的兜底脚本把前面这些检查串成一条命令接手一台陌生虚拟机时先跑一遍输出直接能看到卡在哪一层echo 设备 ; ip -br link echo 地址 ; ip -br addr echo NM状态 ; nmcli device status echo 连接配置 ; nmcli connection show echo 默认路由 ; ip route show default echo DNS ; cat /etc/resolv.conf | grep -v ^# echo 驱动 ; lsmod | grep virtio_net六个段落对应六个层哪一段输出不对劲问题就在哪一层。这个脚本我放在自己的常用命令别名里实测下来比翻笔记快得多。