Virt-manager doesnt find a QEMU connection?

previously it just worked, now not anymore?

I am on Kinoite 39 and layered virt-manager qemu qemu-kvm all the necessary dependencies should be pulled in.

There is a way to run virt-manager in two Distroboxes But i gave up on that for now, as I dont really see the advantage, if starting is such a pain.

Previously, running virt-manager it showed the connection. On rebase, I think I only installed virt-manager and not the qemu packages, which I did afterwards. So probably I just need to delete the virtmanager cache, as now all packages are installed?

qt5-qtvirtualkeyboard-5.15.10-2.fc39.x86_64
virtualbox-guest-additions-7.0.10-1.fc39.x86_64
qemu-device-display-virtio-gpu-8.1.1-1.fc39.x86_64
qemu-device-display-virtio-gpu-ccw-8.1.1-1.fc39.x86_64
qemu-device-display-virtio-gpu-gl-8.1.1-1.fc39.x86_64
qemu-device-display-virtio-gpu-pci-8.1.1-1.fc39.x86_64
qemu-device-display-virtio-gpu-pci-gl-8.1.1-1.fc39.x86_64
qemu-device-display-virtio-vga-8.1.1-1.fc39.x86_64
qemu-device-display-virtio-vga-gl-8.1.1-1.fc39.x86_64
virtiofsd-1.7.0-5.fc39.x86_64
libvirt-libs-9.7.0-1.fc39.x86_64
libvirt-daemon-lock-9.7.0-1.fc39.x86_64
libvirt-daemon-log-9.7.0-1.fc39.x86_64
libvirt-daemon-plugin-lockd-9.7.0-1.fc39.x86_64
libvirt-daemon-proxy-9.7.0-1.fc39.x86_64
libvirt-client-9.7.0-1.fc39.x86_64
libvirt-daemon-common-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-storage-core-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-network-9.7.0-1.fc39.x86_64
libvirt-daemon-config-network-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-storage-disk-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-storage-gluster-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-storage-iscsi-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-storage-iscsi-direct-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-storage-logical-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-storage-mpath-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-storage-rbd-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-storage-scsi-9.7.0-1.fc39.x86_64
libvirt-daemon-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-interface-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-nodedev-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-nwfilter-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-qemu-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-secret-9.7.0-1.fc39.x86_64
libvirt-glib-4.0.0-9.fc39.x86_64
python3-libvirt-9.7.0-1.fc39.x86_64
virt-manager-common-4.1.0-3.fc39.noarch
libvirt-daemon-driver-storage-zfs-9.7.0-1.fc39.x86_64
libvirt-daemon-driver-storage-9.7.0-1.fc39.x86_64
libvirt-daemon-kvm-9.7.0-1.fc39.x86_64
virt-manager-4.1.0-3.fc39.noarch

My user is already in the libvirt group

Edit: I just tried the Distrobox way and it is pretty interesting. But the “browse files” does not work, which doesnt spark joy. Selecting folders works somewhat, but its pretty weird.

distrobox create --root --init --image quay.io/almalinux/8-init:8 --name libvirtd-container
distrobox enter --root libvirtd-container
sudo dnf groupinstall "Virtualization Host" --allowerasing 
sudo systemctl enable --now libvirtd
# Installing ssh stuff
sudo dnf install openssh-server ksshaskpass

sudo cat >> /etc/ssh/sshd_config <EOF
ListenAddress 127.0.0.1
Port 2222
EOF
sudo systemctl enable --now sshd
sudo systemctl restart sshd
sudo passwd root 
# enter any password

Second Distrobox:

distrobox-create Fedora -i registry.fedoraproject.org/fedora-toolbox:39
distrobox-enter Fedora
sudo dnf install virt-manager
distrobox-export --app virt-manager

Create the “libvirt” Desktop launcher:

cat > ~/.local/share/applications/libvirt-container-distrobox.desktop <EOF
[Desktop Entry]
Icon=qemu
Exec=distrobox-enter --root libvirtd-container
Type=Application
Name=libvirt-container
Terminal=true
Categories=System;
StartupWMClass=libvirt
EOF

Then launch virt-manager from the App menu, under “File” add “New connection”

image

The password input field should show up, enter your secure password.


I got this far. Under “create” I should be able to select any .iso and create a VM. But the option “search files locally” is greyed out

adding a directory doesnt let me open a directory inside that, I would need to add every damn diretory containing .iso files


After a reboot virt-manager shows my ISOs! I just tried my Opensuse Slowroll VM and it works well! The app is in english and I have no GPU acceleration though. But so far, great! I will just remove the layered bloat if it works well. Thanks Luca!

I see the same issue, my workaround right now is enabling and starting (the monolithic) libvirtd, after that libvirt works as expected so far. It seems the issue is related to libvirt’s modular architecture, similarly to the recent systemd socket activation issues (I don’t know what causes it now).

I’ve reproduced this on both Kinoite and Silverblue, I don’t have other editions ready to test on.

1 Like

Update: The “reset to defaults” somehow worked now.

So the out of the box experience should just work, with one exception, which is pretty annoying, I have no internet in a Win11 and a Fedora Rawhide VM.

I created the network device as vibr0 (or how its called) and the mode is virtIO.

The Redhat Driver is even recognized in Windows, not sure about the Fedora VM. But no VM has internet connection.

The Windows one doesnt show any network even though connecting the Spice Drivers ISO, installing the gust additions, removing the network driver, reinstalling it, checking for manual updates, it reports as “already using the best driver”.

On the Fedora VM I get a “connected to wifi” but with a warning sign and I have no internet.

The default network first time just worked, how do I create this network?? Win11 may have different troubles and I didnt test that before. But even there all the rest is working great.

Btw is there a way to pass all USB devices at once, or really just one at a time?

If using a libvirt VM the default bridge device created is virbr0.
I use that device by simply telling VMM to use bridged and specifying that device when I create the VM.
If you created a new device named virbr0 then it may be interfering with the default device that libvirt creates automatically.

It also seems that a bridge device attached to a wifi interface may not function. There have been posts here on that issue as well

This is the way mine is set up, and remember I said it was the default virbr0 device

The host shows virbr0 with IP 192.168.124.1 and automatically provides NAT for communications from the VM outbound.

1 Like

hm okay, would be good to know when libvirt creates that network.

I tried creating one manually

  • virbr0 connection
  • virtio mode
  • name: network

I do not remember if it showed as active, this may be a problem

Note that the image I show was from using virt-manager. I use virt manager (VMM) to manage all my VMs and have never had an issue. The virbr0 device is created as soon as you create the first VM with VMM and remains available as long as a single VM is defined, though not active unless a VM has been started.

Libvirt also creates a vnet by default for each VM in use. You can see in this image the vnet1 and vnet2 for the 2 VMs I currently have running. One is rawhide and the other is win11.

Hello @boredsquirrel ,
If you type nmcli it should show you your network connections including the virtual ones. As @computersavvy mentioned libvirt creates virbr0 , it does this when you create the VM in Virt-Manager I think. Anyway, my virbr0 is connected to my lan port as …

enp4s0: connected to Wired connection 1
“Realtek RTL8111/8168/8411”
ethernet (r8169), CE:DD:5F:28:77:57, hw, mtu 1500
master virbr0

While my virbr0 looks like …

virbr0: connected to virbr0
“virbr0”
bridge, CE:DD:5F:28:77:57, sw, mtu 1500
ip4 default
inet4 192.168.0.105/16
route4 192.168.0.0/16 metric 425
route4 default via 192.168.0.1 metric 425
inet6 fe80::7d57:271b:2aaa:7352/64
route6 fe80::/64 metric 1024

Notice it’s a bridge device

And as a note from my experiences, VirtualBox is okay for doing a quick VM setup to test something, but if I need to actually work with it I always use Virt-Manager since it is so much more configurable.

1 Like

The command ip a should show all configured devices with their state, and ip r should show the routing.

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 70:85:c2:93:f7:2c brd ff:ff:ff:ff:ff:ff
3: wlp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 64:49:7d:e5:d3:5a brd ff:ff:ff:ff:ff:ff
    inet 192.168.4.111/22 brd 192.168.7.255 scope global dynamic noprefixroute wlp5s0
       valid_lft 12049sec preferred_lft 12049sec
    inet6 fd8d:e244:853e:1:5ad7:d8ef:4880:85aa/64 scope global dynamic noprefixroute 
       valid_lft 2591867sec preferred_lft 604667sec
    inet6 fe80::c59d:490f:df7:72fa/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:77:64:e8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0
       valid_lft forever preferred_lft forever


 # ip r
default via 192.168.4.1 dev wlp5s0 proto dhcp src 192.168.4.111 metric 600 
192.168.4.0/22 dev wlp5s0 proto kernel scope link src 192.168.4.111 metric 600 
192.168.124.0/24 dev virbr0 proto kernel scope link src 192.168.124.1 linkdown 

Note that I just powered down both VMs I mentioned above so the routing shows linkdown for the virbr0 device.

hmm, I tried creating a new network and activating it, but it doesnt show up in virtmanager. This worked before on a vanilla install, but I would really like to avoid reinstalling.

# define config
echo '<network>
  <name>network</name>
  <bridge name="virbr0" />
  <forward mode="nat" />
  <ip address="192.168.122.1" netmask="255.255.255.0">
    <dhcp>
      <range start="192.168.122.2" end="192.168.122.254" />
    </dhcp>
  </ip>
</network>' > network.xml

# Define and start the network
virsh net-define network.xml
virsh net-start network

# Verify the status
virsh net-info network

# Set the network to autostart
virsh net-autostart network

I tried this, in this order. I restarted the libvirtd service and virt-manager, killed the programs in between. But “network” is not even showing.

To manage virtual networks, you must connect in system mode:

virt-manager -c qemu:///system

qemu:///system vs qemu:///session | Cole Robinson

If the issue persists, it’s likely specific to the immutable variant.

1 Like

Okay somehow it is fixed now. I think I just created a new network that resembles the default one.