Вы здесь

Главная › Форум › Gentoo Linux › Виртуальные машины

Подключение к libvirtd через NAT [SOLVED]

3 июня, 2012 - 22:41 — LinuxID

Доброго времени суток!!!

На работе: Inet <-> NAT <-> libvirtd
Дома: Inet <-> pptp <-> libvirtd

С работы на домашний libvirtd подключаюсь без проблем. Из дома на рабочий libvirtd не получается. При этом на рабочий libvirtd с другой машины в той же сети (рабочей) спокойно подключается.
На NAT проброшены 22 и 5900 порты.

Прошу помощи.

Форум: 
Виртуальные машины
4 июня, 2012 - 22:23 — wi

Способов много.
1) Либвирт умеет соединяться с сервером по протоколу ssh. Если есть возможность добраться к хосту либвирт через ссх вопросов быть не должно. Не работает на вендоклиентах.
2) Проброс порта с любого хоста сети через ссх на локалхост клиента. В данном случае интересует порт либвирта. Будет работать под виндой, и не только с либвиртом.
3) Настройка опенвпн. Требует несколько бОльших усилий, предоставляет прозрачный доступ ко всей сети. Под линем не пробрасывает днс.

5 июня, 2012 - 00:52 — LinuxID

Везде стоит Gentoo ... дома, на шлюзе, там где libvirt и на самих виртуалках (не всех).
Проблема в том что с работы VirtManager чере NAT вполне спокойно коннектится по инету к домашнему libvirtd, а вот из дома через инет и тот же NAT к рабочему libvirtd не получается. При этом входящий 22 порт на NAT`е проброшен на ip сервера виртуалок. По ssh в консоли логинется, а через VirtManager не хочет.

—

Правильно заданный вопрос - половина ответа!
Логики и довода — недостаточно. Надо еще зачморить тех, кто думает не так как мы. (South Park)

5 июня, 2012 - 10:27 — wi

Странно. Значит по варианту 1 так. Подключаемся к виртуализатору по ssh под неким юзером, для примера user. ssh -l user Мой_виртуализатор.
Из сессии user пытаемся выполнить virsh -c qemu:///system. В случае успеха задача частично решена. Можно управлять виртуалками из консоли. Приблизительно так работают клиенты либвирта по протоколу qemu+ssh - организуют соединение и коннектятся к файлу сокета виртуализатора.
Понятно что юзер должен иметь права на файл сокета. Права на сокет выставляются в файле

grep unix_sock /etc/libvirt/libvirtd.conf
unix_sock_group = "wheel"
unix_sock_ro_perms = "0777"
unix_sock_rw_perms = "0770"
unix_sock_dir = "/var/run/libvirt"

Тут у меня выставлена группа wheel. У вам может быть другая. user должен входить в группу. Cокетов два. Один для чтения и один для полного доступа. Тот что на чтение раздается всем.
Проверить наличие юзера в группе grep user /etc/group и права на файлы сокетов ls -lh /var/run/libvirt

Ежели на виртуализаторе virsh сработал можно попробовать зацепится удаленно типа virsh -c qemu+ssh://remoteaddr/system. Да, логи читать полезно на виртуализаторе. Что-то типа tail -f /var/log/messages. Желательно параллельно с подключением.

Для Virt-Manager нужны либо авторизация по ключу либо x11-ssh-askpass. В случае коннекта по ссх через глобальную сеть полезно вообще отключить возможность авторизации по паролю. Иначе пионеры задолбают

10 июня, 2012 - 18:37 — LinuxID

wi написал:
Для Virt-Manager нужны либо авторизация по ключу либо x11-ssh-askpass

Хех ... а вот про это забыл. Спасибо что напомнили. Для авторизации по ключам x11-ssh-askpass тоже нужен. Все, проблема решена. Огромное всем спасибо.

—

Правильно заданный вопрос - половина ответа!
Логики и довода — недостаточно. Надо еще зачморить тех, кто думает не так как мы. (South Park)

Russian Gentoo Linux Community © 2005—2026
Gentoo — торговая марка Gentoo Foundation, Inc.
Сервер работает под управлением Gentoo Linux
Сайт работает под управлением CMS Drupal