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

Wed Jul 22 06:14:16 UTC 2020

Greetings Laine,

> Sent: Tuesday, July 21, 2020 at 9:16 PM
> From: "Laine Stump" <laine at redhat.com>
> To: "libvirt-users at redhat.com" <libvirt-users at redhat.com>
> Cc: "daggs" <daggs at gmx.com>
> Subject: Re: host and vm on isolated network, there is ip (via dhcp) but not ping
>
> On 7/20/20 12:38 PM, daggs wrote:
> > Greetings,
> >
> > I've setup an vm with openwrt in it, defined a isolated lan between the vm and the host and booted the vm up.
> > I see the vm is up, made sure the vnic is visible in both the host and guest and added it to the br in the guest.
> > I've issued an dhcpd call on the vnic (labeled vnic0) in the host and got an ip, see:
> > dagg at NCC-5001D ~ $ dhcpcd vnet0
>
> 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?

that is correct, I assumed dhcod is the dhcp client will query the dhcp server on the vm for an ip.
I'll make sure what does this command supposes to do.

>
> 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.

the configuration that works on the production env was given to me here in this very ml.
I don't think the bridge has an internal dhcp server because the ip given is
part of the range the server provides and I see each action regarding the connection in the router logs
which resides inside the vm.

>
> 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).

there are expect4ed to be 3 other machines on the network, the host, an lan one (via usb pass-through)
and a wireless one (via usb pass-through).
if I setup virtsw0 to provides the ip, there is no reason to have a router inside a vm to begin with.

>
> > DUID 00:01:00:01:23:dd:d8:5b:e0:d5:5e:d9:f2:e2
> > vnet0: IAID 00:10:20:bf
> > vnet0: rebinding lease of 192.168.1.130
> > vnet0: probing address 192.168.1.130/24
> > vnet0: soliciting an IPv6 router
> > vnet0: leased 192.168.1.130 for 43200 seconds
> > vnet0: adding route to 192.168.1.0/24
> > vnet0: adding default route via 192.168.1.1
> > forked to background, child pid 26279
> > dagg at NCC-5001D ~ $ ifconfig
> > virtsw0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> >          ether 52:54:00:3e:3f:88  txqueuelen 1000  (Ethernet)
> >          RX packets 123098  bytes 16327962 (15.5 MiB)
> >          RX errors 0  dropped 0  overruns 0  frame 0
> >          TX packets 6  bytes 252 (252.0 B)
> >          TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> >
> > vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> >          inet 192.168.1.130  netmask 255.255.255.0  broadcast 192.168.1.255
> >          inet6 fe80::fc54:ff:fe10:20bf  prefixlen 64  scopeid 0x20<link>
> >          ether fe:54:00:10:20:bf  txqueuelen 1000  (Ethernet)
> >          RX packets 45  bytes 8002 (7.8 KiB)
> >          RX errors 0  dropped 0  overruns 0  frame 0
> >          TX packets 39  bytes 2676 (2.6 KiB)
> >          TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> >
> > dagg at NCC-5001D ~ $ ping 192.168.1.1
> > PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> > ^C
> > --- 192.168.1.1 ping statistics ---
> > 2 packets transmitted, 0 received, 100% packet loss, time 1018ms
> >
> > the vm's xml can be found at https://pastebin.com/1gXBGcPb
> > virtsw0 is defined as follows:
> > <network connections='1'>
> >    <name>virtsw0</name>
> >    <uuid>c8eb15a3-cc5c-4bd6-8f3b-5790792ddccc</uuid>
> >    <bridge name='virtsw0' stp='on' delay='0'/>
> >    <mac address='52:54:00:3e:3f:88'/>
> > </network>
> >
> > the os is gentoo, the versions are libvirt-6.2.0 qemu-5.0.0.
> > I have another server running debian 10 with the same virtsw0 definition, there the connection is working.
>
>
> Check the iptables rules on both hosts and both guests to see if there
> are any differences.
>

that was one of the first things I looked at, iptables isn't running.

> > /var/lib/libvirt/dnsmasq/virtsw0.macs has only [] in it, can that be the issue?
>
> 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.
>

the reason I felt it is important to check that file is because when I tried to start the vm for the first time, startup filed with an error on /var/lib/libvirt/dnsmasq/ as it didn't existed.
if I don't need it, why starting a vm up require the existent of that folder unconditionally?