Re: virt-manager and qemu: virtual networking missing
On Mon, Oct 27, 2025 at 10:54 AM Charles Curley
<charlescurley@charlescurley.com> wrote:
> On Sun, 26 Oct 2025 08:55:07 +0100
> john doe <johndoe65534@mail.com> wrote:
> > On 10/25/25 21:17, Charles Curley 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'll assume that you have the same error with "virsh net-start
> > default"?
> Correct.
> root@peregrine:~# virsh net-start default
> error: Failed to start network default
> error: internal error: Network is already in use by interface wlp1s0
> root@peregrine:~#
So, what have you got for the configuration for the default network device?
Generally it should be quite functional "out of the box", though possibly
may depend upon various Depends: , Recommends: , or maybe even
Suggested: package(s).
I'd also suggest leave default as it sets it up - should basically work, and
can then also always use that as a reference or alternative, and then if
one wants different and/or alternative network setup(s), create different
separate network configurations for those - and one can then
select/configure for those (even on a per interface basis for the VM)
when creating or modifying the VM (though the VM may need to be
down to change what network an interface is on?)
Anyway, this is what my default has - and you might have to
use root/sudo/su if you don't have your ID set up to access it.
I'm also going to convert any tabs to spaces, and prefix the lines with
"// " - so that might also help thwart email clients from potentially
further messing up the formatting.
$ virsh net-dumpxml default | expand | sed -e 's;^;// ;'
// <network>
// <name>default</name>
// <uuid>4fadc9ec-8fc4-4753-9236-68789b0371d1</uuid>
// <forward mode='nat'>
// <nat>
// <port start='1024' end='65535'/>
// </nat>
// </forward>
// <bridge name='virbr0' stp='on' delay='0'/>
// <mac address='52:54:00:73:80:4c'/>
// <ip address='192.168.122.1' netmask='255.255.255.0'>
// <dhcp>
// <range start='192.168.122.129' end='192.168.122.254'/>
// </dhcp>
// </ip>
// </network>
//
$
That generally provides DHCP (v4) to the VM, NAT/SNAT, dnsmasq, and
routing to one's "main"/default networking and such - of course that
also needs all be quite functional for it to play simply and nicely together,
and of course also need to avoid conflicts with IPs and MAC addresses (e.g.
does one's local (sub)net on primary interface(s) conflict with the range
that the VM setup uses by default? If need be, one can change those).
I forget exactly what it does with v6 - and that might not be as clean
or whatever.
And yes, can set up bridging, but most Wi-Fi hardware doesn't support
bridging, so typically can't do it with most Wi-Fi hardware.
So, my main host I use with VMs, I have both the default (shown above),
and bridged (it's hardwired Ethernet). The full details for all the
networking gets
pretty complex (many subnets, some tunnels, lot of bridging, etc.), so I won't
show that, but I'll show some basics on the other VM network configuration
I also have on that host - which is a relatively basic bridged - and when I use
that it's as if the VM was connected on same network as my main
Ethernet interface - can then do static IPs there, or DHCP v4 +
v6 DHCP and/or ra, etc. (and that happens to be raw unfiltered
Internet there too,
so can put VMs direct on Internet there too, in the case of my network
configuration). Anyway, here's configuration of that network in the
VM
infrastructure, and likewise formatted as above: ...
Oh, yeah, that one there isn't a "network" for it in the VM itself to show,
I just select/configure "bridge" and br0 (the existing bridge device),
so, e.g. --network=bridge=br0 with virt-install, or in VM's config:
$ virsh dumpxml balug | expand | sed -ne
'/<interface/,/<\/interface>/{s;^;// ;;p;}'
// <interface type='bridge'>
// <mac address='52:54:00:13:51:99'/>
// <source bridge='br0'/>
// <model type='virtio'/>
// <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
function='0x0'/>
// </interface>
$
That then effectively puts the interface of that VM directly on my main
Ethernet network (which is also on that bridge device).
I even have some VMs where I put two interfaces on 'em, one to
default (behind NAT/SNAT, etc.), and the other to bridge=br0
for direct raw Internet (e.g. the latter for straight raw IPv6,
the former for IPv4 - don't have so many of those public Internet routable
IPs to work with).
$ brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.72a3e9b34c29 no eth0
vnet3
$
That's what it looks like with one VM actively on that bridge.
Note that one doesn't manually add it (e.g. the vnet3 interface)
to the bridge device, the VM infrastructure automagically handles
that when the VM is started, and likewise removing it when the
VM is down(ed).
Note also that STP would generally be enabled by default and
generally should be enabled. Only disable if you know you
you do not have and would not have any configurations that
could cause a network loop among the switches/bridges,
or more than one possible path that the packets could flow
at layer 2 of the networking.
Of course your uuids, Mac addresses, etc. will vary.
Anyway, hopefully that helps and may give you
more information regarding what to take a (closer) look
at and possibly adjust, etc.
Reply to: