Re: virt-manager and qemu: virtual networking missing
On Sat 25/10/2025 at 20:17, Charles Curley <charlescurley@charlescurley.com> wrote:
> I did a fresh installation of Debian 13 (trixie), and then tried to
> install what I need for virtual machines:
>
> apt install bridge-utils virt-manager dnsmasq-base
>
> I then try to start the default virtual network, and get an error
> message that the network is already in use by interface wlp1s0. Running
> "ip a" shows only the hardware interfaces and lo. The default network
> is looking for virbr0, which does not exist.
>
> I should also have two new zones for libvirt in firewalld; they are
> absent.
>
> What am I missing?
>
> --
> Does anybody read signatures any more?
>
> https://charlescurley.com
> https://charlescurley.com/blog/
Hi Charles,
$ cat /etc/debian_version
13.1
$ ip link
1: lo:
<snip>>
2: eno1:
<snip>>
5: wlx24ec99bfd78d:
<snip>>
6: enx00e04c687cdc:
<snip>
$ sudo apt install qemu-system-x86 libvirt-daemon-system libvirt-clients virt-install virt-manager
Installing:
libvirt-clients libvirt-daemon-system qemu-system-x86 virt-install virt-manager
Installing dependencies:
gir1.2-ayatanaappindicator3-0.1 libphodav-3.0-common libvirt-daemon-driver-storage-mpath
gir1.2-gtk-vnc-2.0 libpmem1 libvirt-daemon-driver-storage-scsi
gir1.2-libosinfo-1.0 librados2 libvirt-daemon-lock
gir1.2-libvirt-glib-1.0 librbd1 libvirt-daemon-log
gir1.2-spiceclientglib-2.0 librdmacm1t64 libvirt-daemon-plugin-lockd
gir1.2-spiceclientgtk-3.0 libslirp0 libvirt-glib-1.0-0
gir1.2-vte-2.91 libspice-client-glib-2.0-8 libvirt-glib-1.0-data
ibverbs-providers libspice-client-gtk-3.0-5 libvirt-l10n
ipxe-qemu libspice-server1 libvirt0
libblkio1 libtpms0 mdevctl
libcacard0 libusbredirhost1t64 netcat-openbsd
libcapstone5 libusbredirparser1t64 open-iscsi
libdaxctl1 libvdeplug2t64 osinfo-db
libexecs1 libvirglrenderer1 ovmf
libfdt1 libvirt-common passt
libgfapi0 libvirt-daemon python3-libvirt
libgfrpc0 libvirt-daemon-common python3-libxml2
libgfxdr0 libvirt-daemon-config-network qemu-block-extra
libglusterfs0 libvirt-daemon-config-nwfilter qemu-system-common
libgtk-vnc-2.0-0 libvirt-daemon-driver-interface qemu-system-data
libgvnc-1.0-0 libvirt-daemon-driver-network qemu-system-gui
libibverbs1 libvirt-daemon-driver-nodedev qemu-system-modules-opengl
libiscsi7 libvirt-daemon-driver-nwfilter qemu-system-modules-spice
libisns0t64 libvirt-daemon-driver-qemu qemu-utils
libndctl6 libvirt-daemon-driver-secret seabios
libopeniscsiusr libvirt-daemon-driver-storage spice-client-glib-usb-acl-helper
libosinfo-1.0-0 libvirt-daemon-driver-storage-disk swtpm
libosinfo-l10n libvirt-daemon-driver-storage-iscsi swtpm-libs
libphodav-3.0-0 libvirt-daemon-driver-storage-logical swtpm-tools
<snip>
Summary:
Upgrading: 0, Installing: 92, Removing: 0, Not Upgrading: 10
Download size: 57.2 MB
Space needed: 243 MB / 433 GB available
<snip>
$ ip link
<no difference>
$ sudo usermod -aG libvirt,kvm [username]
[log out and in again]
$ virt-manager
<set up debian 13.1 xfce live>
Dialog
"Virtual Network is not active.
Virtual Network 'default' is not active. Would you like to start the network now?" [Yes]
[a bit later]
Dialog
"Emulator may not have search permissions for <path>. Do you want to correct this now?" [Yes]
VM starts with LiveCD menu
On Host:
$ ip link
<snip>
7: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:ba:26:9d brd ff:ff:ff:ff:ff:ff
10: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether fe:54:00:1c:7a:9c brd ff:ff:ff:ff:ff:ff
On Debian Live VM:
user@[LiveVM]:~$ ip a
1: lo:
<snip>
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
<snip>
user@[LiveVM]:~$ ping google.com -c1
PING google.com (142.250.129.100) 56(84) bytes of data.
64 bytes from lclhrb-in-f100.1e100.net (142.250.129.100): icmp_seq=1 ttl=109 time=12.1 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 12.084/12.084/12.084/0.000 ms
But iirc you can't access VM inwards from host or (W)LAN/internet without further ado.
"Bridging with a wireless NIC
Just like you can bridge two wired ethernet interfaces,
you can bridge between an ethernet interface and a wireless interface." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
https://wiki.debian.org/BridgeNetworkConnections#Libvirt_and_bridging
"Inside an intranet or home lab, a NAT-based network gives VMs outbound network access.
If VMs are running services that must be accessible from other systems on the LAN, create a Bridged network (for an Ethernet connected libvirt host)
or a Routed network (for a wirelessly connected libvirt host)."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
https://jamielinux.com/docs/libvirt-networking-handbook/index-full.html
"The typical configuration for guests is to use bridging of the physical NIC on the host to connect the guest directly to the LAN. In RHEL6 there is also the possibility of using macvtap/sr-iov and VEPA connectivity. None of this stuff plays nicely with wireless NICs, since they will typically silently drop any traffic with a MAC address that doesn't match that of the physical NIC.
Thus the virtual network driver in libvirt was invented. This takes the form of an isolated bridge device (ie one with no physical NICs attached). The TAP devices associated with the guest NICs are attached to the bridge device.
This immediately allows guests on a single host to talk to each other and to the host OS (modulo host IPtables rules)."
^^^ THIS DOESN'T SEEM TO BE TRUE (any more, nor for a number of years) ^^^
https://libvirt.org/firewall
"Host configuration (bridged)
The NAT based connectivity is useful for quick & easy deployments, or on machines with dynamic/sporadic networking connectivity. More advanced users will want to use full bridging, where the guest is connected directly to the LAN. The instructions for setting this up vary by distribution, and even by release.
Important Note: Unfortunately, wireless interfaces cannot be attached to a Linux host bridge, <<<
so if your connection to the external network is via a wireless interface ("wlanX"), <<<
you will not be able to use this mode of networking for your guests." <<<
https://wiki.libvirt.org/Networking.html
I've struggled with guest to host access before and couldn't remember where I'd seen relevant bridging/wifi info.
ChatGPT found the following, which matches largely with my memory and most refs appear to be supportive of assertions/hallucinations etc:
====
"... most Wi-Fi network interfaces do not support being part of a Linux bridge, which is why bridged networking typically doesn’t work when your host is connected via Wi-Fi. This isn’t a libvirt limitation per se, but a limitation of how IEEE 802.11 wireless and Linux bridging interact.
Here are the key sources where this is explained:
🧩 1. libvirt Networking Documentation
Official source:
🔗 https://libvirt.org/network.html
“It is generally not possible to use a wireless (Wi-Fi) interface for a network bridge, because the IEEE 802.11 protocol does not support the promiscuous mode needed to forward traffic for multiple MAC addresses.”
2. Linux Bridge Documentation
Kernel docs:
🔗 https://www.kernel.org/doc/Documentation/networking/bridge.txt
The Linux bridge code relies on being able to forward Ethernet frames at layer 2. Most Wi-Fi NICs, however, only allow frames with the host’s own MAC address due to how 802.11 association works (clients are tied to one MAC address in managed mode). Bridging would require forwarding frames with other MACs, which isn’t allowed in that mode.
3. libvirt FAQ and Community Discussions
https://wiki.libvirt.org/page/Networking#WiFi
https://lists.libvirt.org/archives/list/users@lists.libvirt.org/
[^ this is unavailable and the first link doesn't contain the quote]
“WiFi interfaces cannot be enslaved to a bridge in the usual way. If you need your guests to access your LAN over WiFi, use routed or NAT networking instead.”
Workarounds
If you need your VM to appear on the same LAN while on Wi-Fi, you can:
Use macvtap networking in “bridge” mode (not the same as a real bridge, but similar),
Or set up NAT networking (default virbr0 network),
Or use IP forwarding + ebtables rules (complex and still not true bridging).
=====
IIRC VirtualBox used to allow host to guest communication and vice-versa, I think by setting up macvtap. I've never got that to work for libvirt, partly due to frustration with old tutorials containing much iptables gobbledegook. Things may have improved, I last tried about 10 years ago.
HTH
Gareth
Reply to: