virt-manager: Cannot recv data: Connection reset by peer

[Ceppo]

Context: I am on sid, so random breakage is expected. This time it happened
somewhere between virt-manager and KVM, and I got stuck as I don't know much
about KVM and emulation general.

I have been using virt-manager to manage virtual machine with QEMU/KVM user
session for some months without any issue. From monday the session is "Not
Connected" and when I try to connect I get the following message:

Unable to connect to libvirt qemu:///session.

Cannot recv data: Connection reset by peer

and Details:

Unable to connect to libvirt qemu:///session.

Cannot recv data: Connection reset by peer

Libvirt URI is: qemu:///session

Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 923, in _do_open
self._backend.open(cb, data)
File "/usr/share/virt-manager/virtinst/connection.py", line 171, in open
conn = libvirt.openAuth(self._open_uri,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/libvirt.py", line 147, in openAuth
raise libvirtError('virConnectOpenAuth() failed')
libvirt.libvirtError: Cannot recv data: Connection reset by peer

I supposed something happened when I upgraded my (host) machine with aptitude
full-upgrade, and in fact aptitude logs include the following:

[UPGRADE] libvirt-daemon-driver-qemu:amd64 10.3.0-3 -> 10.4.0-1
[UPGRADE] python3-libvirt:amd64 10.3.0-1 -> 10.4.0-1
[UPGRADE] qemu-block-extra:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-system-common:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-system-data:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-system-gui:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-system-modules-opengl:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-system-modules-spice:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-system-x86:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-utils:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2

But I couldn't find anything interesting in their changelogs.
The usual online forums digging suggested to make sure that libvirtd is active
[1] - and it does. I also experimented with solutions proposed for similar but
different issues, to no avail. Here I got stuck.
Someone can help me investigate or resolve the issue?



[1]: https://bbs.archlinux.org/viewtopic.php?id=289546z



--
Ceppo

[Bruno Kleinert]

Post by Ceppo
Context: I am on sid, so random breakage is expected. This time it happened
somewhere between virt-manager and KVM, and I got stuck as I don't know much
about KVM and emulation general.
I have been using virt-manager to manage virtual machine with QEMU/KVM user
session for some months without any issue. From monday the session is "Not
Unable to connect to libvirt qemu:///session.
Cannot recv data: Connection reset by peer
Unable to connect to libvirt qemu:///session.
Cannot recv data: Connection reset by peer
Libvirt URI is: qemu:///session
File "/usr/share/virt-manager/virtManager/connection.py", line 923, in _do_open
self._backend.open(cb, data)
File "/usr/share/virt-manager/virtinst/connection.py", line 171, in open
conn = libvirt.openAuth(self._open_uri,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/libvirt.py", line 147, in openAuth
raise libvirtError('virConnectOpenAuth() failed')
libvirt.libvirtError: Cannot recv data: Connection reset by peer
I supposed something happened when I upgraded my (host) machine with aptitude
[UPGRADE] libvirt-daemon-driver-qemu:amd64 10.3.0-3 -> 10.4.0-1
[UPGRADE] python3-libvirt:amd64 10.3.0-1 -> 10.4.0-1
[UPGRADE] qemu-block-extra:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-system-common:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-system-data:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-system-gui:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-system-modules-opengl:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-system-modules-spice:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-system-x86:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
[UPGRADE] qemu-utils:amd64 1:8.2.4+ds-1 -> 1:8.2.4+ds-2
But I couldn't find anything interesting in their changelogs.
The usual online forums digging suggested to make sure that libvirtd is active
[1] - and it does. I also experimented with solutions proposed for similar but
different issues, to no avail. Here I got stuck.
Someone can help me investigate or resolve the issue?
[1]: https://bbs.archlinux.org/viewtopic.php?id=289546z
--
Ceppo

Hi Ceppo,

FWIW, if you're running firewalld on that machine that seems somewhat
related:
https://libvirt.org/firewall.html#firewalld-and-the-virtual-network-driver

I'm affected by the same issue, digged a little around but still have
no clue what's going wrong.

Regards,
Bruno

[Ceppo]

Post by Bruno Kleinert
FWIW, if you're running firewalld on that machine that seems somewhat
https://libvirt.org/firewall.html#firewalld-and-the-virtual-network-driver
I'm affected by the same issue, digged a little around but still have
no clue what's going wrong.

Hi Bruno, thanks for answering!
I don't have firewalld installed, but your message let me explore the issue
again and reading some forum threads I found something weird.
Just after I boot my system, virt-manager behaves the same as a few weeks ago
and the default network is not active:

***@mypc:~$ sudo virsh net-info default
Name: default
UUID: e2a6d5a1-e57e-4281-ad59-6af1f54112e2
Active: no
Persistent: yes
Autostart: no
Bridge: virbr0

Also, if I run `sudo virsh net-destroy default`, I get the expected result:

error: Failed to destroy network default
error: Requested operation is not valid: network 'default' is not active

But if I run virt-manager after that, it connects to the user session but
the network doesn't work for guest machines - which makes sense.

Is this of any use to understand what's the issue? If you can't help, I think I
will file a bug report.


--
Ceppo