Re: Connectivity for a qemu guest; was Re: Connection of a qemu guest to the 'net.

[Berto Furth]

Hi Peter,

> Berto & all,
> 
> The qemu guest here now has full connectivity.

Brilliant. Thanks for going to the effort of documenting exactly what you did 
and how you got it to work. I'm sure that will help lots of people in the 
future.
 
> These are my notes about differences from "ordinary" qemu usage.
> 
> (1) This qemu host is also a Linux router.  It has Shorewall installed.

Oh I see. That would make things difficult in terms of converting your main 
router IP address from being associated with a physical Ethernet to a bridge 
interface.
 
> (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.

In regards to identifying the bridge interface automatically, I don't think 
that's a great idea. These auto detect bridge style scripts assume that you 
want to connect your guests to the same bridge network that you're using for 
your real internet connectivity and that's not always the case. Especially in 
your case where the firewall and the QEMU host are one and the same. Much 
cleaner to manually create the bridge, tailor it to your needs and then specify 
the bridge in the scripts directly in my view....but that's just my opinion.

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

Agreed. Many people probably don't want to screw around with their router's 
configs.

> Comments, corrections, suggestions welcome.
> 

You're a legend for getting this working and sharing the results. Thanks Peter!

Berto.

> Regards,                                ... P.
> 
> -- 
> cell: +1 236 464 1479            Bcc: peter at easthope. ca
> VoIP: +1 604 670 0140
> 
> 
>