Networking limitation with VM networking in ZimaOS?

Insight & Feedback
1

I’m running into a networking limitation with VM networking in ZimaOS.

When selecting:

“Bridge to eth0”

for a VM network interface, I would expect this to behave like a real Linux bridge (for example br0), where:

  • the VM receives a normal LAN IP

  • host ↔ VM communication works

  • ARP functions normally

  • the VM behaves like a regular device on the LAN

However, in practice it appears ZimaOS/libvirt is using macvtap instead of a true Linux bridge.

Symptoms:

  • the VM receives a valid LAN IP

  • the VM can reach other LAN devices

  • the VM cannot reach the ZimaOS host itself

  • ARP resolution to the host fails (“No route to host” / FAILED neighbor)

This exactly matches the known macvtap host-isolation limitation.

As a result, scenarios such as:

  • reverse proxies (Caddy/Nginx)

  • Home Assistant on the host

  • VM ↔ host service communication

do not work correctly.

Questions:

  • Is ZimaOS intentionally using macvtap for “Bridge to eth0”?

  • Is support for a real Linux bridge (br0) available or planned?

  • Is there a recommended method for enabling proper host ↔ VM communication?

For homelab and reverse proxy use cases, true bridged networking is often essential.

2

What issues do you expect with Home Assistant in a VM?

I am running HA in a ZimaOS VM (ZVM) with no issues as far as I can tell.

I have one NIC bridged and it has been assigned an IP from my DHCP server. I don’t know if it can talk to the host but tbh I don’t know why it would need to.

Perhaps this means my setup is simple/broken, or perhaps it means it’s not using macvtap?

3

Thanks for the feedback.

I think our setups are slightly different.

In your case, Home Assistant is running inside a VM with its own bridged IP address, so communication with the ZimaOS host is probably not required.

In my setup:

  • Home Assistant runs directly on the ZimaOS host as a Docker container using network_mode: host

  • Caddy runs inside a VM

  • The VM therefore needs to reach a service running on the ZimaOS host itself (192.168.1.19:8123)

What I observed was:

  • The VM could reach other LAN devices

  • The VM could not reach the ZimaOS host

  • ARP resolution for the host failed (FAILED neighbour entry)

  • Switching the VM to NAT mode immediately restored connectivity to the host

That behaviour seems consistent with the well-known macvtap host-isolation limitation.

So the issue is not that bridged networking itself is broken, but rather that VM-to-host communication appears not to work when using “Bridge to eth0”.

Have you ever tried reaching a service running directly on the ZimaOS host from inside your VM?