e1000: Detected Tx Unit Hang - VMware Workstation 17.6.3 Pro - HAOS 15.2/HA Core 2025.6.2
Describe the issue you are experiencing
Been running HA via VMware Workstation Pro for years now without issue. Maybe 1.5 months ago or so started having issues.
When the web interface hangs and no longer loads, on the VMware workstation window I see the e1000: Detected Tx Unit Hang message just printing over and over again. I have to manually stop the VM and restart it. It locks up within a few days.
What operating system image do you use?
ova (for Virtual Machines)
What version of Home Assistant Operating System is installed?
15.2
Did the problem occur after upgrading the Operating System?
No
Hardware details
Windows 11 Pro i7-8700 32GB RAM
VMWare Workstation Pro 17.6.3 build-24583834 Only HA VM running
Allocated to HA VM: 2.5GB RAM 2 Processors 32GB hard disk
Steps to reproduce the issue
- Launch VM
- Wait for VM to hang - HA app/web GUI connection will not work
- Check via host's VMware Workstation application HA VM & see repeating "e1000: Detected Tx Unit Hang" messages in console ...
Anything in the Supervisor logs that might be useful for us?
Not that I can tell
Anything in the Host logs that might be useful for us?
Not that I can tell
System information
No response
Additional information
No response
What adapter type do you use? Maybe try using VMXNET 3 (paravirtualized network device, HAOS should support it) or E1000E.
I use the default, which is the e1000. According to what I could find, it does support the e1000e as well, but when I attempted to manually update the *.vmx config file by changing the ethernet0.virtualDev = "e1000" to "e1000e," the VM would no longer boot. Not sure why.
I did have someone recommend the VMXNET 3 as well, and I attempted to change that same line to use it and it again wouldn't boot.
I then found @ https://www.home-assistant.io/installation/alternative/ that "Use the E1000 or E1000E virtual network adapter. There are confirmed mDNS/Multicast discovery issues when using VMware’s VMXnet3 virtual network adapter." Just FYI.
Hm, there are some results on Google where this seems to be a problem. We use vanilla upstream Linux, so that really seems to be some interaction problem between Linux and VMware 🤷
Maybe disabling hardware tso helps? Enter this on the OS shell (use login on the ha prompt to get os shell access)
nmcli con modify "Supervisor eth0" ethtool.feature-tso on
nmcli con up "Supervisor eth0"
(replace connection name with the current active one shown in nmcli con show)
Finally happened again. Made the recommended changes. Thank you for the step-by-step. Is there any way for me to confirm that the changes took effect?
ethtool is not available in the root shell. But you can use the "Advanced SSH & Web Terminal" add-on which runs on host network and install ethtool using apk add ethtool, then check using ethtool -k enp0s18 | grep tcp-segmentation-offload. It should be set to "off" after the change is applied.
Made the changes and it happened again.
Since this is a VM could you not simply choose another NIC type and potentially reset the network?
Also what did ethtool say when used as instructed above?
I have the exact same issue. The VM doesn't boot when trying to change the adapter.
Doesn't boot is not enough information to help. What does it show?
I have the same issue did anyone find a fix?
I have the same situation on a pretty fresh and very vanilla installation of the haos 16.2 ova in VMWare. If anyone has a solution I would love to know.
Same happening here;
- ESXi 7.0u3 (too stingy to upgrade it)
- HAOS guest deployed from 16.3 OVA here; https://www.home-assistant.io/installation/alternative/
- Observed the warning to use "E1000" or "E1000E" adaptor - went with E1000
- Experiencing periodic hangs exactly like others here
- Observed the ESXi Guest Compatibility is an ancient 5.5 - could this be related?
Switching to virtualHW.version = "17" and ethernet0.virtualDev = "e1000e" seems to have fixed it on Workstation, at least I haven't been getting any crashes since then.
Switching to
virtualHW.version = "17"andethernet0.virtualDev = "e1000e"seems to have fixed it on Workstation, at least I haven't been getting any crashes since then.
when I do that "ethernet0.virtualDev = "e1000e" or VMXNET 3 it won't boot for me anymore, changing the bootorder in vm bios will not keep after reboot.