[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Connectivity for a qemu guest; was Re: Connection of a qemu guest to the
From: |
peter |
Subject: |
Connectivity for a qemu guest; was Re: Connection of a qemu guest to the 'net. |
Date: |
Fri, 19 Mar 2021 09:33:07 -0700 |
Berto & all,
The qemu guest here now has full connectivity.
These are my notes about differences from "ordinary" qemu usage.
(1) This qemu host is also a Linux router. It has Shorewall installed.
(2) Somewhere there's mention of connecting the bridge to the
interface to the Internet. Ie. the bridge is assigned the IP address
of the Internet interface along with the address for the subnet of the
qemu guest. Here the bridge has the qemu address but not the Internet
gateway address.
peter@joule:/home/peter$ ip addr show dev br0
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group
default qlen 1000
link/ether 1e:e9:74:a2:5a:ef brd ff:ff:ff:ff:ff:ff
inet 172.23.6.1/24 brd 172.23.6.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fd99:9999:9999:9999::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::745f:e4ff:fe9f:67b0/64 scope link
valid_lft forever preferred_lft forever
172.23.6.0/24 is the subnet of the qemu guest.
Internet connectivity of the qemu guest is achieved by this line in
/etc/shorwall/snat .
MASQUERADE 172.23.6.0/24 $NET_IF
(3) The script /etc/qemu-ifup provided in Debian 10 qemu finds the
interface for the default route; in this case wlxe894f6248352 .
peter@joule:/home/peter$ ip route ls
default via 172.20.10.1 dev wlxe894f6248352
172.20.10.0/28 dev wlxe894f6248352 proto kernel scope link src 172.20.10.3
172.23.4.0/24 dev eth0 proto kernel scope link src 172.23.4.1 linkdown
172.23.5.0/24 dev enx0050b60be9be proto kernel scope link src 172.23.5.1
linkdown
172.23.6.0/24 dev br0 proto kernel scope link src 172.23.6.1
wlxe894f6248352 is not the bridge interface and consquently qemu-ifup
fails to establish a tap interface. Consequently no connectivity.
This was corrected with Berto's qemu-ifup which names the bridge
explicitly.
If someone sees a way to identify the bridge interface automatically
without assuming it is the default route, the Debian qemu-ifup can be
improved.
(4) Q: Why does qemu involve a bridge rather than only routing?
A: My hypothesis. Routing requires adjustment of iptables. Direct
editing of iptables is difficult and error prone for non-experts. An
alternative is to use Shorewall or similar functionality. Shorewall
is large package. Imposing dependance of qemu on Shorewall will be
unwelcome to some users. A bridge is an expedient solution.
Comments, corrections, suggestions welcome.
Regards, ... P.
--
cell: +1 236 464 1479 Bcc: peter at easthope. ca
VoIP: +1 604 670 0140