The issue you're encountering on Debian 13 ARM where virsh list --all returns no virtual machines, but sudo virsh list --all does, is likely related to permissions or group membership not being properly applied. Here’s how to diagnose and fix it:

Root Cause

1. Group Membership:

   • The libvirt group grants access to manage virtual machines via virsh without sudo.
   • Even if your user is in the libvirt group, the group permissions might not be applied to the current session.

2. Session Refresh:

   • Group changes (e.g., adding a user to libvirt) require a new login session to take effect.
   • If you added your user to the libvirt group recently, you may need to log out and log back in or restart your terminal session.

3. Polkit Rules:

   • On some systems, virsh requires Polkit (PolicyKit) permissions to allow non-root users to interact with libvirtd.
   • If Polkit is misconfigured, it may block access even for users in the libvirt group.

4. AppArmor/SELinux:

   • If AppArmor or SELinux is enabled, it might restrict access to libvirtd for non-root users.

5. Libvirt Socket Permissions:

   • The Unix socket used by libvirtd (typically /var/run/libvirt/libvirt-sock) must be accessible by the libvirt group.
   • Check its permissions with:
     bash

     Copy

     ls -l /var/run/libvirt/libvirt-sock

   • It should look like:
     text

     Copy

     srw-rw---- 1 root libvirt 0 [date] /var/run/libvirt/libvirt-sock

   • If not, fix it with:
     bash

     Copy

     sudo chown root:libvirt /var/run/libvirt/libvirt-sock
     sudo chmod 660 /var/run/libvirt/libvirt-sock

Steps to Fix

1. Verify Group Membership

Run:

groups

Ensure libvirt is listed. If not, add your user to the group:

sudo usermod -aG libvirt $USER

Then log out and log back in (or restart your terminal).

2. Check Libvirt Socket Permissions

Run:

ls -l /var/run/libvirt/libvirt-sock

If the group is not libvirt or permissions are not 660, fix it as shown above.

3. Restart libvirtd

Restart the libvirtd service to apply changes:

sudo systemctl restart libvirtd

4. Check Polkit Rules

If Polkit is used, ensure there are rules allowing the libvirt group to manage VMs. Check for Polkit-related errors in:

journalctl -u polkit --no-pager -n 50

If needed, create a Polkit rule file (e.g., /etc/polkit-1/rules.d/50-libvirt.rules) with:

polkit.addRule(function(action, subject) {
    if (action.id == "org.libvirt.unix.manage" &&
        subject.isInGroup("libvirt")) {
        return polkit.Result.YES;
    }
});

Then restart Polkit:

sudo systemctl restart polkit

5. Check AppArmor/SELinux

• For AppArmor:

  bash

  Copy

  sudo aa-status

  If libvirtd is confined, try temporarily disabling AppArmor:

  bash

  Copy

  sudo systemctl stop apparmor

  Test if virsh list --all works. If it does, adjust the AppArmor profile for libvirtd.

• For SELinux (less common on Debian):

  bash

  Copy

  sudo sestatus

  If enabled, check for denials:

  bash

  Copy

  sudo ausearch -m avc -ts recent

  Temporarily set SELinux to permissive mode to test:

  bash

  Copy

  sudo setenforce 0

6. Test with LIBVIRT_DEFAULT_URI

Explicitly set the URI for virsh to use the system connection:

export LIBVIRT_DEFAULT_URI="qemu:///system"
virsh list --all

If this works, add the export line to your ~/.bashrc or ~/.profile.

7. Check libvirtd Logs

Look for errors in:

journalctl -u libvirtd --no-pager -n 50

Summary of Commands to Run

# 1. Verify group membership
groups

# 2. Fix group membership if needed
sudo usermod -aG libvirt $USER
# Log out and back in

# 3. Check socket permissions
ls -l /var/run/libvirt/libvirt-sock
sudo chown root:libvirt /var/run/libvirt/libvirt-sock
sudo chmod 660 /var/run/libvirt/libvirt-sock

# 4. Restart libvirtd
sudo systemctl restart libvirtd

# 5. Test with URI
export LIBVIRT_DEFAULT_URI="qemu:///system"
virsh list --all

Expected Outcome

After applying these fixes, virsh list --all should work without sudo. If the issue persists, the problem might be specific to your Debian 13 ARM setup (e.g., a bug or missing package).