On Sat 25/10/2025 at 20:17, Charles Curley <[email protected]>
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/[email protected]/
[^ 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
