SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Virtualization New Added 19 September 2026

libvirt: Failed to connect socket to /var/run/libvirt/libvirt-sock

virsh connected to the session daemon rather than the system one, or the user is not in the group that owns the socket. The same command works under sudo, which is the clue: it is a permission and URI problem, not a daemon that failed to start.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Which URI is being used, and is the system daemon running
virsh uri
systemctl status libvirtd virtqemud

# qemu:///session has its own socket and cannot see system VMs
virsh --connect qemu:///system list --all
export LIBVIRT_DEFAULT_URI=qemu:///system

# Group membership is the usual gap. Log out and back in, id alone does not refresh
sudo usermod -aG libvirt $USER
newgrp libvirt
id -nG

# Confirm the socket ownership matches that group
ls -l /var/run/libvirt/libvirt-sock

# Modular daemons: the socket is socket activated, so enable the socket unit
sudo systemctl enable --now virtqemud.socket

# Access can also be granted by polkit rules rather than group membership

How to diagnose Virtualization errors

Virtualisation errors are usually about hardware virtualisation access: either it is disabled in firmware, or another hypervisor already holds it. On Windows, Hyper-V, WSL 2, Docker Desktop, Credential Guard and memory integrity all claim the virtualisation extensions, and VirtualBox or VMware then fails with a message that mentions VT-x but not the actual conflict.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Confirm virtualisation is enabled at the CPU level: grep -E 'vmx|svm' /proc/cpuinfo on Linux, or the Performance tab of Task Manager on Windows.
  2. On Windows, check what else is using the hypervisor: bcdedit /enum | findstr hypervisorlaunchtype and whether Hyper-V, WSL 2 or Core Isolation are enabled.
  3. On Linux, check /dev/kvm exists and that your user is in the kvm group; nested virtualisation must be enabled explicitly on cloud VMs.
  4. Match guest additions and tools versions to the hypervisor version: mismatches cause shared folders, clipboard and display problems that look like guest OS bugs.
  5. For WSL, run wsl --status and wsl --update; most WSL 2 errors are a stale kernel or a disabled Virtual Machine Platform feature.

Tools worth reaching for

  • grep -E 'vmx|svm' /proc/cpuinfo
  • wsl --status
  • bcdedit /enum
  • ls -l /dev/kvm
  • systemctl status libvirtd

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

libvirt.org libvirt.org

Related Virtualization errors

See all 11 Virtualization errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.