virt-manager не может подключиться к libvirt

После установки KVM выполните эту команду, чтобы эта ошибка больше не возникала.

sudo virt-manager

Альтернативой перезагрузке / выходу из системы является запуск следующих команд из терминала:

newgrp libvirt
virt-manager

newgrp Команда позволяет пользователю присоединиться к libvirt группа без выхода из системы, для процессов, которые запускаются в той же оболочке после newgrp, Конечно, это работает, только если установщик libvirt поместит вас в группу libvirt, которую вы можете проверить с помощью:

getent group libvirt

Для меня ошибка была вызвана тем, что изменения членства в группе не применяются без входа в систему (или перезагрузки). Я только что установил KVM и libvirt-bin. Программа установки автоматически добавила моего пользователя в группу libvirtd, я перезапустил службу libvirt-bin, но все еще получал сообщение об ошибке.

Простой выход из системы и ее повторное решение решили проблему путем применения моего нового членства в группе.

Предполагая, что вы только что установили libvirt-bin и уже подтвердили, что ваш текущий пользователь является членом группы libvirtd, как следует из сообщения об ошибке, вам нужно будет выйти из системы и снова войти в нее, чтобы применить новое членство в группе.

Не изменяйте права доступа к файлам на 777. Не просто запускайте все с правами root или sudo, чтобы избежать понимания, что не так.

Я надеюсь, что это помогает кому-то.

Вошедший пользователь должен быть добавлен в libvirtгруппа пользователей

      sudo usermod -a -G libvirt $USER

Я управляю как Qemu, так и Virtualbox на моем компьютере с Ubuntu 14.02, и после установки Virtualbox libvirt-bin не удалось автоматически запуститься. Поэтому проверьте, работает ли libvirt-bin:

ps faux | grep libvirt-bin

если вы не видите его в выводе ps - запустите вручную, затем запустите virt-manager:

sudo service libvirt-bin start

На Ubuntu 16.04.3 LTS

systemctl start virtlogd.socket

был единственный ответ. Сокет имеет своего собственного демона. Это необычно

Для меня дело было в том, что при использовании service libvirt-bin status это показало, что все просто работает нормально, хотя я не мог подключиться, как:

    ● libvirt-bin.service - Virtualization daemon
       Loaded: loaded (/lib/systemd/system/libvirt-bin.service; enabled; vendor preset: enabled)
       Active: active (running) since Do 2016-09-22 13:22:16 CEST; 6min ago
[...]

В /var/run/libvirt/ там должны быть эти два файла:

srwxrwxrwx  1 root libvirtd    0 Sep 22 13:22 libvirt-sock=
srwxrwxrwx  1 root libvirtd    0 Sep 22 13:22 libvirt-sock-ro=

Если розетки не отображаются, используйте service libvirt-bin stop; service libvirt-bin start полностью перезапустить процесс. С помощью service libvirt-bin restart недостаточно и не создаст заново сокет.

libvirt-bin Сервис может быть безопасно остановлен и не отключит гостей.

После установки всех пакетов, указанных в операторе, вы можете выйти из системы, а затем снова войти в нее. Все, что добавляет вас в группы пользователей, необходимо для выхода из системы и входа в нее для добавления в новые группы. Это небольшое неудобство, меньше одного, чем перезагрузка.

Это было помечено как незавершенное, однако это является общим правилом для добавления вашего пользователя в группу. Необходим перелог, это была недостающая часть, которую я не видел здесь.

Для меня это было решением:

sudo apt install libvirt-daemon-system

sudo systemctl start libvirtd

перезапустить систему

Пользователь в libvirt группа может бежать virt-manager а также virsh без sudo.

$ sudo gpasswd libvirt -a <username> 
$ cat <<EOF | tee -a ~/.profile
export VIRSH_DEFAULT_CONNECT_URI=qemu:///system 
EOF 
$ sudo reboot

Проблема обсуждается на Launchpad, и причину этой проблемы можно решить, установив xen-utils пакет (xen-utils-4.4 на Ubuntu 14.04). Я ранее обошел эту проблему virt-manager через sudo в командной строке.

Различные ответы ссылаются на тот факт, что проблема может возникнуть из-за того, что групповые разрешения не применяются к пользователю, работающему с диспетчером виртуальных машин, и принятый ответ, отмечающий, что перезагрузка устранила проблему, вполне возможно, зависит от перезагрузки, чтобы дать пользователю группу разрешения при входе в систему (хотя перезагрузка также может запускать службы).

В случае Ubuntu 20.04.1 установка QEMU/KVM с помощью apt-get автоматически запускала все службы и в конечном итоге разрешалась строго путем выяснения того, как предоставить пользователю, работающему с доступом к группе Virtual Machine Manager (хотя показало, что пользователю были предоставлены права).

Как упоминают другие, выход из системы/вход в систему обычно необходим для регистрации новых групповых разрешений, но в случае использования графического рабочего стола GNOME выхода из системы и повторного входа в систему было недостаточно для предоставления пользователю GUI новых групповых прав. Фактически, выхода из системы И перезапуска, остановки всех экземпляров оболочки GNOME) и повторного входа в систему было недостаточно.

В одном сценарии следующее было эффективным и не требовало перезагрузки после установки :

• где пользователь входит в GNOME.
• sudo systemctl restart gdm

Команда была получена из этого ответа .

Перезагрузка потребовалась, потому что после запуска графическая консоль закрылась, не предложив экран входа в систему (оставив только черный экран). Не было определено, является ли всегда убивает графический механизм входа в систему, но если это не так, то перезапуск может быть излишним (опущен).

Для справки, в случае, когда это решение сработало, был установлен путем установки: , , , а также . Это правильно запустило необходимые службы без ручного вмешательства и автоматически назначило групповые права ранее существовавшим пользователям с правами sudo.

Я столкнулся с той же проблемой. попробуй запустить виртуальный менеджер через sudo

      sudo virt-manager

Я просто следовал этому руководству . Чего мне не хватало:

      sudo systemctl enable libvirtd.service
sudo systemctl start libvirtd.service

Простое исправление: перейдите в учетные записи и измените свои группы на обе libvirt группы.

Начиная с Ubuntu 17.10, я также должен был добавить себя в группу libvirt. Я уже добавил себя в libvirtd и не удалил себя из этой группы. Я не знаю, требуются ли оба или нет.

Я сделал это, так как заметил, что содержимое /var/run/libvirt принадлежит libvirt, а не libvirtd.

Используйте Ubuntu Software для удаления виртуального менеджера, выхода из системы, входа в систему, установки виртуального менеджера и запуска его в обычном режиме без использования sudo или даже с помощью командной строки.

У меня была такая же проблема, и в подробном отчете об ошибке говорится о недостатке разрешения на libvirt-sock файл. Изменение разрешения файла /var/run/libvirt/libvirt-sock до 777 заставил его работать на меня.