If a ZimaOS VM using “Bridge to eth0” receives a normal LAN IP and can reach other LAN devices but cannot reach the ZimaOS host itself, the behavior matches the well-known macvtap host-isolation pattern. In the original thread, switching the VM to NAT immediately restored VM-to-host connectivity.
However, the thread did not include an IceWhale confirmation that ZimaOS definitely implements that option with libvirt macvtap. The correct wording is therefore symptom-based: it behaves like macvtap isolation, rather than claiming the internal implementation as a documented fact.
The Symptom Pattern Is Highly Specific
- The VM receives a DHCP address on the physical LAN.
- The VM can reach routers and other LAN devices.
- The VM cannot ARP or connect to the ZimaOS host IP.
- NAT mode restores access to services running on the host.
This is different from a VM that has no network at all. It mainly affects workflows where the guest must call a service bound directly to the ZimaOS host.
Why This Looks Like macvtap
Libvirt's macvtap host-isolation guide documents the same pattern: a guest using a direct/macvtap interface can reach the external network but cannot directly communicate with its virtualization host.
The current libvirt network format reference also distinguishes a pre-existing host bridge from a macvtap direct connection and notes the host-to-guest limitation of macvtap.
Use NAT When the VM Must Reach ZimaOS Host Services
In the community test, NAT mode was the verified workaround. If a reverse proxy inside the VM only needs outbound access to a service on the ZimaOS host, NAT may be simpler than forcing a LAN-bridged interface.
If the guest also needs a first-class LAN address, a second VM interface on a host-reachable virtual network is a common libvirt pattern, but whether ZVM exposes that cleanly depends on the current ZimaOS UI and version.
Design the Reverse Proxy Around the Network Boundary
If Caddy or Nginx runs in a VM while Home Assistant or another service runs directly on the ZimaOS host, verify host reachability before spending time on TLS or proxy configuration. The ZimaOS reverse proxy guide is useful once basic Layer-3 connectivity works.
For general interface and IP configuration, the ZimaOS device connection guide provides a separate baseline.
Bottom Line
The thread verifies the networking symptom and the NAT workaround. It does not verify the exact ZimaOS implementation. Treat “macvtap” as the best technical explanation for the observed host isolation unless current IceWhale documentation confirms the backend explicitly.
