开头
虚拟机SMB传输速度慢，优先检查SMB协议版本、网卡虚拟化类型和巨帧配置，这三项占大多数性能瓶颈的七成以上。剩下的因素多与存储后端和TCP卸载功能相关，按下面顺序逐项排查，多数情况下能把速度从几十MB/s拉到接近物理机水平。
为什么你的虚拟机SMB传输速度跑不满带宽
虚拟机内部跑SMB协议与物理机完全不同,数据路径多了一层虚拟化封装，每一步都可能成为瓶颈，传输慢通常不是SMB本身的问题，而是虚拟网络链路中的某一环拖了后腿。
先判断瓶颈在虚拟化层还是协议层
Windows共享到Windows共享,速度不到100MB/s，问题多半在虚拟交换机或网卡类型，Linux虚拟机和Windows宿主互传时，SMB版本不匹配也经常出现速度腰斩的情况，用iperf3测一下虚拟机之间的裸TCP吞吐量，如果裸网络本身就低，问题锁定在网络虚拟化层，如果iperf3跑满万兆或千兆带宽，那问题就出在SMB协议协商或SMB配置上。
虚拟交换机对SMB传输的影响机制
ESXi的vmxnet3、Hyper-V的合成网卡、KVM的virtio-net都依赖驱动与虚拟交换机的配合，部分场景下，默认的e1000或RTL8132模拟网卡需要CPU逐包模拟，传输速率会被压在300Mbps左右，这就是为什么新装虚拟机经常出现百兆级拷贝速度的根源。
软件层优化：SMB协议与多通道设置
确认SMB协议版本没有协商成旧版
SMB 1.0在Windows 10和Server 2016之后默认禁用，但老系统或NAS设备可能回退到SMB 1.0或2.0，这两代没有多通道和目录租约缓存，速度差距极大。
在传输慢的宿主机或虚拟机上,用PowerShell执行以下命令确认协商版本：
Get-SmbConnection | Format-List ServerName, DialectVersion
如果显示的是SMB 2.0或更低的版本，需要检查对方设备是否支持SMB 3.0及以上，Windows Server 2016以上支持SMB 3.1.1，速度和安全都是最优解。
开启SMB多通道和自动调优
SMB 3.0及以上版本自带多通道功能，在多网卡或多路径的场景下能自动叠加带宽，在虚拟机设置中额外添加一块虚拟网卡，然后在PowerShell中开启：
Set-SmbClientConfiguration -EnableMultiChannel $true
服务器端也需要确认：
Set-SmbServerConfiguration -EnableMultiChannel $true
服务端开启后不必重启,重新建立SMB会话即可生效，开设多块网卡后，SMB会基于源IP与目标IP的组合自动使用多条TCP连接并行传输，前提是各网卡处于不同的子网或负载均衡模式下，常见坑是两块网卡同时挂在同一个vSwitch下但没有配置不同的vLAN或IP网段，导致流量仍走单一路径。
关闭SMB压缩可能带来的CPU额外开销
Windows Server 2026引入SMB压缩功能，对低带宽网络有帮助，但在高带宽局域网环境下反而增加CPU占用，传输慢且CPU被打满时可以关闭：
Set-SmbClientConfiguration -DisableCompression $true
更新的Windows Server 2026将SMB压缩算法改为LZ4，默认开启，对于纯SSD存储的阵列建议保持压缩开启，压缩率虽低但速度影响可忽略，如果存储后端是机械硬盘阵列或NAS盒子，关掉压缩能减轻CPU负载，整体吞吐量更稳定。
虚拟化平台网络配置的优化路径
每个主流虚拟化平台在SMB传输上的优化点略有差异,以下按平台拆解。
VMware ESXi下的SMB性能提升
第一步，确认虚拟网卡型号是VMXNET3。 在ESXi 7.0及以上版本中新建的虚拟机默认使用VMXNET3，但老虚拟机从物理机迁移而来可能还挂在E1000上，修改虚拟机配置，把网卡改为VMXNET3后，升级VMware Tools并重启客户机。
第二步，开巨帧。 在vSwitch属性中把MTU改为9000，同时在虚拟机操作系统中把虚拟网卡MTU改为9000，Windows下的命令：
netsh interface ipv4 set subinterface "以太网" mtu=9000 store=persistent
Linux下用ip命令或直接修改Netplan配置,巨帧让单包承载更多数据，降低CPU中断次数，千兆网络下提升约15%，万兆网络下提升约30%。
第三步，确认vSwitch的负载均衡算法是Route based on physical NIC load而非originating virtual port。
ESXi默认的基于源虚拟端口的路由不会跨物理网卡分发流量，多块物理网卡汇聚时只有一块在工作。
Hyper-V平台SMB传输优化清单
Hyper-V的默认虚拟交换机性能本身不错，但要注意以下几点：
- 把MAC地址欺骗和DHCP Guard关闭，这两个选项在SMB多会话场景下可能造成包丢弃
- 在虚拟机设置中启用SR-IOV，前提是物理网卡支持且驱动程序允许
- Hyper-V 2019+支持将SMB流量直接映射到物理RDMA网卡，虚拟机内需要安装专用的SMB加速驱动
不建议在虚拟交换机上开启端口镜像或扩展ACL，这些功能会强制让VMM的CPU参与转发，直接拉低吞吐。
Proxmox VE下的SMB传输调整
Proxmox默认使用virtio-net，Windows虚拟机需要安装viostor和netkvm驱动，若传输不稳定，改在半虚拟化模式下运行或加装多队列功能：
在VM配置文件中加入：
args: -device virtio-net-pci,netdev=net1,mq=on,vectors=6同时保证物理网卡的队列数不低于虚拟机vCPU数量,Ceph存储场景下的SMB慢，更多是存储延迟问题，而非网络问题。
网络适配器设置：TCP卸载和中断调节
虚拟网卡同样有TCP Offload功能，部分老驱动或特定虚拟化平台对Checksum Offload处理有bug，导致大量无效重传，遇到SMB拷贝速度锯齿状波动时，关闭RSS和TCP/UDP校验和卸载，多数场景下速度曲线会变得平滑。
Windows设备管理器 网络适配器 属性 高级标签下的相关选项：
- 关闭Large Send Offload (LSO)
- 关闭Receive Side Scaling (RSS)的CPU亲和性绑定，让多核自动分担
- 开启Interrupt Moderation，减少中断风暴
VMXNET3推荐保留硬件卸载和RSS开启,因为vmxnet3的驱动经过VMware维护，卸载执行效率远高于操作系统软件处理，E1000或Realtek模拟网卡则要完全关闭卸载功能。
存储后端：被忽略的关键变量
SMB传输速度最终受限于读取和写入的介质速度,虚拟机把数据从虚拟磁盘读出再通过SMB发送，再从SMB写入另一块虚拟磁盘，任何一环的存储IOPS不够，SMB速度都是空谈。
虚拟磁盘格式的选择对传输速度的影响
- 厚置备延迟置零格式写入时分配空间,首次写入速度快，适合SMB传输常涉及的临时文件缓存
- 精简置备格式首次写入触发存储分配,造成延迟波动
- 直通物理磁盘RDM或物理透传模式最适合大文件SMB共享任务
生产环境中用vSphere 8的虚拟机和群晖NAS做SMB传输，若虚拟磁盘和NAS均使用机械硬盘，那么SMB速度上限由机械硬盘的持续写入速度决定，约为150-200MB/s，此时无论怎么调SMB参数都无法突破物理极限，加SSD缓存或改用全闪存储是唯一出路。
常见问题排查Q&A
排查虚拟机SMB传输速度慢的正确顺序是什么？
先测裸TCP吞吐量排除网络层,再用smbstatus（Linux Samba环境）或Get-SmbConnection确认协议版本，最后看存储IOPS，这三个步骤能定位九成以上的SMB慢速问题。
SMB 3.0和SMB 2.0在虚拟机场景下的传输差异有多大，需要升级吗？
SMB 3.0引入多通道和SMB Direct（RDMA支持），在支持多网卡虚拟机的场景下差异显著，双千兆网卡聚合场景中，SMB 3.0能把速度从SMB 2.0的约100MB/s提升到180MB/s以上，再加上目录租约缓存，大量小文件读写的提升更明显，不建议继续使用SMB 2.0。
NAS上虚拟机SMB共享速度慢，有哪些独有优化项？
多数NAS默认开启了SMB签名,禁止访客访问和SMB 1.0，但不会自动开启SMB多通道，群晖和威联通都需要在控制面板的SMB高级设置中手动勾选启用SMB 3.0多通道，NAS上的传输慢与NFS相比有个通病：SMB对文件锁的处理更重，数据库类虚拟磁盘放在NFS上速度更稳定，纯粹的文件共享则保留SMB。
最后的结论很简单：先把虚拟网卡换成半虚拟化或合成类型，确保SMB协议协商到3.0以上，然后开启巨帧和多通道，最后检查存储底层的IO能力。 这套组合拳打完，虚拟机的SMB传输速度基本能达到物理机常规水准的八成以上，剩下的差距主要来自虚拟化层固有的CPU开销和协议开销，属于不需要再折腾的正常范围。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/628072.html
