Re: host and vm on isolated network, there is ip (via dhcp) but not ping

On 7/20/20 12:38 PM, daggs wrote: You didn't run "dhcpd" (which is a dhcp server) on the host, you ran "dhcpcd", which is a dhcp *client*. So you've ended up assigning an IP address to the tap device on the host. I guess the dhcp server that's issuing this IP address is part of openwrt in the guest? A tap device on the host that is attached to a bridge is merely a conduit between the guest's emulated NIC and the bridge device on the host, and should not have its own IP address (although it may work in certain cases, yours apparently being one of them, since you say the same setup works on a debian 10 host; hmm - maybe in the debian host you had been running dhcpcd on the bridge device rather than the tap?). In general when there is a bridged connection on the host, the IP address for the guest should be on the emulated network device *in the guest*, and the IP address for the host side of that connection should be on the bridge device in the host, *not* the tap device. Now if the openwrt guest and the host are the only two entities communicating on this connection, then you could put an IP address on the tap device directly, but in that case you wouldn't want the tap to be attached to a bridge anyway. If that's the case, just define the interface in the guest as something like this: <interface type='ethernet'> <mac address='52:54:00:10:20:bf'/> <source> <ip address='192.168.1.130' prefix='24'/> </source> <model type='virtio'/> </interface> The IP address inside <source> will set the IP of the *host* side of the tap device. You can also add routes to the host's routing table inside <source>. See https://libvirt.org/formatdomain.html#ipconfig for details (it is very important to remember that the <ip>/<route> *inside the <source> element* is used to set the IP address of the host side of the tap. An <ip>/<route> as a toplevel subelement of <interface> is intended to set those properties *in the guest*, and won't work at all in the case of qemu, since the hypervisor in that case has no visibility into the guest's IP network configuration). Check the iptables rules on both hosts and both guests to see if there are any differences. Since in your case the host is a dhcp *client*, that is irrelevant. I'm actually surprised that the file exists at all, since you have no <dhcp> section in your network definition, so dnsmasq should even be run.