Virbr0 device is always down

Hi Ant

Q: Why Ubuntu doesn't have virtnetworkd?

A: Going modular is an optional configuration step and rather disruptive to the integration of libvirt into the system. There is continuous work to make this smoother, but it wasn't sufficient yet - therefore it isn't configured and build that way yet. It will be some day, but for now virtnetworkd and any virt*d are not missing, they are just part of the old style monolithic libvirtd.

Q: libvirtd create device without interfaces, so I couldn't bring it up and it does not work

A: On my 22.04.1 things work just fine, but maybe it is just a lack of detail in your request.
Your output likes like that of "brctl show" and an empty bridge (actually a bridge in nat mode to be more specific). Looks like this:

$ brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.525400d7d5df yes

Configured (the default) via:
$ virsh net-dumpxml default
<network>
  <name>default</name>
  <uuid>ebd0dd56-10b5-45e9-abfe-bd5dc15b20e9</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:d7:d5:df'/>
  <ip address='192.168.123.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.123.2' end='192.168.123.254'/>
    </dhcp>
  </ip>
</network>

So the bridge has a host network interface (virbr0 itself) but no associated interfaces right now. If I attach guests then it gets interfaces attached like veth03fabd4e.

All seems to work fine, but I'm sure you have a more specific need and configuration, yet missed to outline what and how you do. That is the default of "install libvirt, and it works", anything you configure/change in your setup would be great to be explained here.
-> Setting to incomplete until we understand the issue.

Note:
You didn't explain how you instruct libvirt to create your bridges, which is important to try to recreate your problem and to try to help further.
General instructions how to do bridges via netplan and use them in libvirt are at [1], have you done it like that?

[1]: https://netplan.io/examples#configuring-network-bridges

Hello! About my use case. I try to run VM with Gnome Boxes but it does not automatically switch to bridge networking on Ubuntu like it does on Fedora with virtnetworkd service running. It uses user mode SLIRP, instead
Also, it does not show an IP in VM preferences (gnome boxes) on Ubuntu

is_libvirt_bridge_net_available
https://gitlab.gnome.org/GNOME/gnome-boxes/-/blob/main/src/util-app.vala#L315

Thank Ant for explaining your case with a bit more detail.

I'm not an expert in gnome-boxes (only used it a few times, but have no depth in it yet), but AFAIK it uses user permissions and due to that also libvirt user-session (qemu:///session vs the usual Ubuntu admin virtualization usage of system wide qemu:///system).

Libvirt does - on install - set up a reasonable (nat) default network for qemu:///system and has done so for all the time. But we do not do so for each qemu:///session (we can't as there might even be later users added, users that do not want this, ...).
Ubuntu users even of Desktop/UI tools traditionally use qemu:///system as well, like virt-manager.

But gnome-boxes follows the qemu:///session approach where daemons and virtual machines are not system, but user owned. That is a different concept and perfectly fine to use, but not the default we set up libvirt for.

I'd expect any less system and more user centric solution to set up these on install/creation.
That would make it a gnome-boxes problem in the first place. I'm adding a bug tasks for gnome-boxes people to chime in and coordinate what/if we'd need.
When doing so, maybe we even need a libvirt-* package to augment that, but even in that case we'd still need to learn from gnome-boxes what exactly is needed.

One reason users do not easily create bridged networking is that it is a security sensitive task and needs privileges. A lot of this is around qemu-birdge-helper which for security reasons does not come with setuid out of the box. To open it up intentionally an admin has to do a few changes which are outlined in many places, but since it is making things less secure not in an official place. This covers it rather well:
https://askubuntu.com/questions/1234102/trouble-getting-a-bridge-working-with-gnome-boxes

@people looking for the gnome-boxes bug task, is there something we can do to make this smoother for you other than making the classic system hypervisor setup less secure by default? Could you throw a popup to ask for admin power to do those changes? A special package you depend on that sets it up that way (libvirt-unsecure-user-network :-/ ). Or might it be even time to revisit with security the very old decisions to make it not default setuid?
Waiting for your input on how we could continue, until then the libvirt task is incomplete.

P.S. AFAICS right now this issue does not seem purely Ubuntu specific, but should affect all Debian derived distributions. So whatever we end up doing let us do it in all of them. And while it isn't related to the split daemons (virtnetworkd vs libvirtd) we could try to get it implemented smoother either way.

@paelzer
Thank you very much!