Libvirt connection leaks
After a morning of provisioning VMs on libvirt where the VMs failed to install packages (could not fetch glibc-common rpm so anaconda failed to finish), the libvirt compute resource became unreachable with the message in UI of
Call to virConnectOpen failed: End of file while reading data: Ncat: Connection reset by peer.: Input/output error
/var/log/messages on the libvirt host indicated
libvirtd: Too many active clients (20), dropping connection from 127.0.0.1;0
Restarting the rails server freed up the connections and the compute resource was usable again.
It appears that libvirt connections are being held onto by the server.
#4 Updated by Lukas Zapletal over 5 years ago
- Subject changed from libvirt connections not closed - Call to virConnectOpen failed: End of file while reading data: Ncat: Connection reset by peer.: Input/output error to Libvirt connection leaks
I think the best way to handle this is to create SimpleConnectionManager that will provide a block opening and closing connection automatically. Then we need to rewrite all our code to blocks.
This opens up doors for implementing PooledConnectionManager (e.g. via https://github.com/mperham/connection_pool gem) later on, so we can re-use connections. The gem assumes self-healing connections which is not the case for libvirt, so the manager need to implement "ping" check before every call and heal the broken connections. For libvirt this can be implemented via fog with the "get_node_info" call which raises
Libvirt::RetrieveError: Call to virNodeGetInfo failed: internal error: client socket is closed
on broken connections.
#7 Updated by Lukas Zapletal 7 months ago
- Triaged changed from No to Yes
Please increase the following values
#max_anonymous_clients = 20
#max_workers = 20
in /etc/libvirt/libvirtd.conf and restart libvirtd daemon. The libvirt daemon in RHEL is not configured for heavy concurrent client use, we generally do recomment oVirt or Red Hat Enterprise virtualization for enterprise workloads.