Подключение к libvirtd через NAT [SOLVED]
LinuxID 3 июня, 2012 - 22:41
Доброго времени суток!!!
На работе: Inet <-> NAT <-> libvirtd
Дома: Inet <-> pptp <-> libvirtd
С работы на домашний libvirtd подключаюсь без проблем. Из дома на рабочий libvirtd не получается. При этом на рабочий libvirtd с другой машины в той же сети (рабочей) спокойно подключается.
На NAT проброшены 22 и 5900 порты.
Прошу помощи.
»
- Для комментирования войдите или зарегистрируйтесь
Способов много. 1) Либвирт
Способов много.
1) Либвирт умеет соединяться с сервером по протоколу ssh. Если есть возможность добраться к хосту либвирт через ссх вопросов быть не должно. Не работает на вендоклиентах.
2) Проброс порта с любого хоста сети через ссх на локалхост клиента. В данном случае интересует порт либвирта. Будет работать под виндой, и не только с либвиртом.
3) Настройка опенвпн. Требует несколько бОльших усилий, предоставляет прозрачный доступ ко всей сети. Под линем не пробрасывает днс.
Везде стоит Gentoo ... дома,
Везде стоит Gentoo ... дома, на шлюзе, там где libvirt и на самих виртуалках (не всех).
Проблема в том что с работы VirtManager чере NAT вполне спокойно коннектится по инету к домашнему libvirtd, а вот из дома через инет и тот же NAT к рабочему libvirtd не получается. При этом входящий 22 порт на NAT`е проброшен на ip сервера виртуалок. По ssh в консоли логинется, а через VirtManager не хочет.
Правильно заданный вопрос - половина ответа!
Логики и довода — недостаточно. Надо еще зачморить тех, кто думает не так как мы. (South Park)
Странно. Значит по варианту 1
Странно. Значит по варианту 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. В случае коннекта по ссх через глобальную сеть полезно вообще отключить возможность авторизации по паролю. Иначе пионеры задолбают
wi написал(а): Для
Хех ... а вот про это забыл. Спасибо что напомнили. Для авторизации по ключам x11-ssh-askpass тоже нужен. Все, проблема решена. Огромное всем спасибо.
Правильно заданный вопрос - половина ответа!
Логики и довода — недостаточно. Надо еще зачморить тех, кто думает не так как мы. (South Park)