Unusably slow Bridged network upload after upgrading host to Tahoe

[kohenkatz]

Describe the issue

When running macOS 15 Sequoia, network performance inside macOS VMs was roughly equivalent to the host's performance. After upgrading the host to macOS 26 Tahoe, the upload side of network connections has become much slower and often unreliable.

I first noticed this because a VM that was running GitLab CI jobs was timing out when sending 150MB files back to the GitLab server. The Activity Monitor's Network tab showed that upload speed was maxing out at about 250Kbps. I confirmed that the same upload process run from the host to the GitLab server is multiple Mbps (it finished too fast for me to see the result in the Activity Monitor.)

I tested with VMs running Sequoia and Tahoe, and I see the same problem in both of them.

I normally run these VMs in Bridged Network mode, so I can connect to them with VNC from another computer on the same local network, and I observed that the VNC drawing is incredibly slow, which is consistent with very poor upload speed. When I switch them to Shared Network mode, the network speed is normal, but then I cannot access them from my other machines.

Configuration

• UTM Version: 4.7.4 (originally seen on 4.6.3, upgraded hoping for a fix)
• macOS Version: 26
• Mac Chip (Intel, M1, ...): M4

Crash log

N/A

Debug log

There is nothing in my system log other than generic "ASL Sender Statistics" info messages.

Upload VM

This happens with all VMs that use Bridged Networking. I created a plain VM with no changes and copied in a large file to test with, and it did the same thing.

[jjlauer]

Experiencing the same issue. Fortunately, after digging around for a few hours, I found a workaround! Looks like disabling TSO on the network for the guest VM fixes the issue (or at least minimizes it!). Based on this: https://knowledge.broadcom.com/external/article/315599/slow-upload-speed-in-macos-guests-with-v.html

Try it out:

sudo sysctl -w net.inet.tcp.tso=0

Then to make it permananet - create a file /etc/sysctl.conf and add a below entry

net.inet.tcp.tso=0

[kohenkatz]

Thanks @jjlauer, I'll try that.

But it's still very weird that this seems to only be happening after I did an OS upgrade, while that article is two years old...

[kohenkatz]

It looks like CircleCI gives the same recommendation: https://support.circleci.com/hc/en-us/articles/19334402064027-Troubleshooting-slow-uploads-to-S3-for-jobs-using-an-m1-macOS-resource-class

[kohenkatz]

It definitely makes a difference for me!

[taku3arakaki-sketch]

The same issue occurs even when the guest OS is Linux Ubuntu 24.04. I think it needs to be addressed on the UTM side.

[taku3arakaki-sketch]

Disabling TCP TSO also worked as a workaround for Ubuntu guest systems, just like it did for macOS guest systems.

Run the following command in the guest OS:

1. Check the current hardware offload settings. sudo ethtool -k | grep tcp-segmentation-offload

2. Disable TCP TSO sudo ethtool -k tso off

[frang75]

This also works for me. Thanks @jjlauer

Experiencing the same issue. Fortunately, after digging around for a few hours, I found a workaround! Looks like disabling TSO on the network for the guest VM fixes the issue (or at least minimizes it!). Based on this: https://knowledge.broadcom.com/external/article/315599/slow-upload-speed-in-macos-guests-with-v.html

Try it out:

sudo sysctl -w net.inet.tcp.tso=0

Then to make it permananet - create a file /etc/sysctl.conf and add a below entry

net.inet.tcp.tso=0

[joseftw]

This worked for me on Ubuntu 25.10, went from 1mbit to 950...

sudo ethtool -K enp0s1 tx off gso off gro off