在OpenStack虚拟机里用ethtool查看网卡配置是完全可行的，操作路径和物理机几乎一致，但输出结果里像速率、队列数、offload这些参数，必须结合virtio虚拟网卡的背景来解读，否则很容易误判。这套方法适用于排障、性能调优和日常巡检，下面从进入虚拟机开始,一步步说清楚。
进入OpenStack虚拟机前，先确认接口名别认错
OpenStack默认的虚拟网卡模型是virtio，操作系统里通常显示为eth0、ens3或enp0s3，取决于镜像使用的命名规则，你登录虚拟机后，第一件事不是急着敲ethtool,而是先跑一条命令确认哪个接口是业务网卡。
ip link show
- 如果看到
state UP且有IP地址的接口,就是主网卡。 - 如果有多块网卡，比如管理网和存储网分离，要对着
ip addr里的IP段去认，别拿管理网卡查业务流量,查出来的统计毫无参考价值。
这里有个小坑：某些OpenStack镜像会启用一致的网络设备命名，接口名是enp0s0f0之类，看着像物理机接口，实际还是virtio虚拟网卡，别被名字骗了，用ethtool -i看驱动才是硬道理。
OpenStack虚拟机用ethtool查看网卡配置的完整操作
ethtool是个功能很密集的命令，查看场景常用的就是下面这几个子命令，逐个拆开说,每个都对应一类排查需求。
ethtool查看网卡速率和链路状态
直接跑
ethtool eth0
Speed字段会显示速率，比如10000Mb/s，但这只是virtio驱动上报的默认值,不代表物理链路真的跑在万兆。Duplex正常是Full，如果看到Half,大概率是驱动或虚拟交换机配置出了问题。Link detected: yes表示虚拟机侧认为链路是通的，这里注意，虚拟机的链路状态其实由宿主机上的虚拟交换机端口决定,不完全是网卡硬件状态。
如果你想看的是宿主机物理网卡的速率，在虚拟机里是看不到的，得登录计算节点，用ethtool查宿主机的物理接口，比如ens1f0,这是OpenStack排障里最常见的认知盲区。
ethtool -i 查驱动和固件，认准virtio_net
ethtool -i用来查看网卡驱动信息,在OpenStack虚拟机里这条命令尤其重要。
ethtool -i eth0
输出里重点关注：
- driver字段：OpenStack默认是
virtio_net，如果显示i40e或mlx5_core，说明这块网卡是通过SR-IOV直通进来的物理VF,行为逻辑和普通virtio网卡完全不同。 - firmware-version：物理网卡会显示固件版本，virtio网卡通常为空或显示
N/A。 - bus-info：virtio网卡的bus-info是
virtio0这类虚拟地址，物理网卡显示的是真实的PCI地址，比如0000:3b:00.1。
行业共识认为，先看driver再下结论是OpenStack网络排障的第一步，很多看起来像物理网卡的问题，查完驱动发现是虚拟设备,排查方向就得换。
ethtool -l 查看网卡队列数，关系到收发性能
网卡队列数决定了多核CPU能否并行处理网络包,在虚拟机里跑：
ethtool -l eth0
- 如果输出里
Combined字段显示当前值1，限制是1,说明是单队列网卡。 - 如果当前值
4、限制8,说明是多队列已开启或可扩容。
OpenStack里创建的虚拟机默认可能只分配了单队列，但镜像里装了multiqueue驱动的话，可以在flavor或镜像属性里开启多队列，业内专家指出，多队列对高并发网络场景的吞吐影响相当大，尤其在NFV或DPDK这类场景下,队列数直接决定包转发能力。
顺便说一句，ethtool -L可以修改队列数，但在云主机里改完重启基本就还原了，底层配置得在OpenStack侧改,别在虚拟机里白费功夫。
ethtool -k 查看offload，虚拟网卡和物理网卡差异最明显的字段
ethtool -k eth0
查看网卡卸载特性,重点关注：
- tcp-segmentation-offload：一般显示
on，表示TCP分段卸载由网卡接管,CPU省不少事。 - generic-segmentation-offload：普通场景保持
on，但如果跑抓包分析，建议临时关闭，否则抓到的是分段后的大包,看着很困惑。 - rx-checksumming：virtio网卡通常支持接收校验卸载,下行大流量时能降低CPU占用。
OpenStack场景里，offload异常是虚拟机网卡丢包和延迟飙升的常见诱因，但老实说，这类问题多数出在宿主机虚拟交换机层面，虚拟机里看到的值往往是驱动上报的,物理网卡的真实卸载能力在虚拟化层已经被抽象掉了。
ethtool -S 查看网卡统计，丢包排查的入口
ethtool -S eth0
输出里字段很多，比如rx_queue_0_packets、tx_queue_0_dropped，优先看带drop和error的计数器。
- 如果
rx_dropped持续增加,先看是不是环形缓冲区太小。 - 如果
tx_timeout有增长,多半是驱动或虚拟交换机卡住了。
再补一条常用命令：
ethtool -g eth0
查看环形缓冲区大小，rx和tx的当前值如果只有256或512，在高并发下容易丢包，可以尝试调大，但同样的问题：重启失效,要考虑从镜像或OpenStack配置层面固化。
ethtool查看网卡配置时，virtio网卡和物理机有哪些差异
核心差异在于，ethtool的输出在虚拟网卡上有一部分是模拟的，不是真实硬件探测的。
- 速率值：virtio网卡上报的速率是驱动写死的默认值,不代表物理链路协商结果。
- ring buffer：virtio的环形队列是内存里的数据结构，扩容受宿主机内存和CPU限制,不像物理网卡那样有硬件深度限制。
- offload能力：virtio网卡支持一部分卸载特性，但不等于宿主机物理网卡的全部offload能力,两者中间还隔着一层虚拟交换机。
- 统计计数器：虚拟网卡的丢包计数更像是在虚拟化层记账,和物理网卡的硬件计数器含义不完全等同。
反过来，如果虚拟机绑定的是SR-IOV VF直通网卡，ethtool输出就基本接近物理网卡的表现，速率、固件、PCI地址都是真实的，所以看到业务网卡驱动不是virtio_net，等你查完SR-IOV网卡配置，记得顺手确认VF的MAC地址和虚拟机内匹配,不然网络会不通。
OpenStack虚拟机网卡丢包问题用ethtool怎么排查
网卡丢包是云主机排障里最头疼的问题，按下面顺序查,能省不少时间。
-
先确认丢包发生在哪一层
在虚拟机里跑ethtool -S eth0，看rx_dropped和tx_dropped。 -
如果虚拟机的网卡计数器没有丢包，但业务确实丢包
问题在宿主机虚拟交换机或物理网卡上，登录计算节点，用ethtool -S查物理网卡统计，看rx_missed和rx_fifo_errors。 -
检查环形缓冲区是否过小
虚拟机里跑ethtool -g eth0，如果当前值远小于限制值,先尝试临时调大看看效果。 -
检查队列利用率
多队列网卡但只有一个队列在跑，吞吐上不去就是这原因，用ethtool -l eth0确认队列数，再配合top看CPU中断分布，如果中断都打在一个核心上,说明多队列没生效或者RSS没配置好。 -
关闭offload做对比测试
这条是排除法：临时跑ethtool -K eth0 rx on tx on，看丢包是否变化，如果关闭后丢包消失，说明offload路径有bug,考虑更新驱动或调整虚拟交换机配置。
这套流程在多数情况下能定位到丢包的大致层级，至少能区分是虚拟机内部问题还是宿主机问题，后续找运维还是自己改配置,方向不会错。
相关问答：OpenStack虚拟机用ethtool查看网卡配置的常见问题
OpenStack虚拟机里ethtool能看到物理网卡信息吗
默认不行，普通virtio网卡模式下，虚拟机里的ethtool只能看到虚拟网卡信息，包括虚拟MAC、virtio驱动和模拟的速率，想看到物理网卡信息，只有两种情况：一是使用SR-IOV透传，把物理VF直接分配给虚拟机；二是登录宿主机,在计算节点上查看物理网卡。
ethtool和ip命令哪个查看网卡信息更准
两者定位不同，ip命令侧重查看网络层和链路层的状态，比如IP地址、接口up/down、MAC地址和基本的统计，但看不到速率协商、驱动版本、offload能力、环形缓冲区这些详细参数，ethtool才是查看网卡底层配置和卸载特性的专用工具，排查物理链路和驱动问题时,用ethtool是正解。
在OpenStack虚拟机里用ethtool改网卡参数，重启后失效怎么办
这是因为ethtool的修改只作用于当前运行时，不写入配置文件，有两个思路：一是把ethtool命令写入虚拟机的开机启动脚本，比如rc.local或者systemd服务，但镜像重建后一样会丢；二是从OpenStack层面处理，比如镜像里预置配置文件，或者在虚拟机创建后通过cloud-init注入了ethtool配置脚本,后一种方式更符合云环境的管理习惯。
归根结底，OpenStack虚拟机用ethtool查看网卡配置，核心就一句话：能看，但要带着虚拟化的眼睛看，先确认驱动类型，再解读具体字段，最后结合宿主机侧信息做交叉验证，这套方法用的次数越多,你对云上网络排障的把握就越准。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/631742.html
