On Sat, Apr 17 2010, Вереск wrote:
Забавное наблюдение: при использовании vde виртуалка видится отовсюду,
кроме, собсно, хоста :-) Ну или я опять недоглядел маршруты.
Кроме, собсно, хоста это к vde_pcapplug (точнее, к её отсутствию).
Проверьте: ip route get ип.вир.туал.ки должен возвращать
А можно поподробнее, пошагово как оно работает и как его настроить? Там
точно соблюдены требования из моего первого сообщения?
А что вам мешает и из виртуальной машины запустить openvpn клиент,
соединиться с сервером и получить желаемый ip ?
У меня все kvm машины соединяются с openvpn при
On Fri, Apr 16 2010, Вереск wrote:
Что-то и где-то я явно не уловил.
1. Про -net vde даже на офсайте написана исчерпывающая информация:
vde
another option is using vde (virtual distributed ethernet).
-net
On Fri, Apr 16 2010, Вереск wrote:
kvm -drive file=/home/veresk/fuse/Windows.qcow,if=virtio,boot=on -net
nic,model=virtio -net vde,sock/tmp/myswitch -m 1024
Unknown network device: vde
В данном случае ядро самосборное, 2.6.32
Судя по диагностике, этого не умеет именно kvm. Так что этот путь
On Fri, Apr 16 2010, Вереск wrote:
Наверное, это не важно (если обновляться не будете). -net nic создаёт
сетевую карту в VM, а параллельное ему -net vde (как и все остальные
фиговины вроде -net tap) втыкает эту карту в свитч.
Список -net nic'ов сопоставляется поэлементно списку
-net
On Fri, Apr 16 2010, Вереск wrote:
с -net vde то ли лыжи не едут, то ли...
Порядок дейсвий:
vde_switch -F -sock /tmp/mys3 -d
/home/veresk # kvm -drive file=/home/veresk/fuse/Windows.qcow2,boot=on
-net nic,model=virtio -net vde,sock=/tmp/mys3 -m 1024 -cdrom
On Fri, Apr 16 2010, Anton Kovalenko wrote:
Пинги между виртуальными машинами, воткнутыми в один и тот же vde_switch
(т.е. с одним и тем же sock=) должны ходить без участия реальных
интерфейсов хоста. Возможно, вам будет удобно начать именно с этого.
Кстати, ещё одна неоговорённая деталь:
On Fri, Apr 16 2010, Вереск wrote:
192.168.1.5 - реальный интерфейс хозяина - 0 реакции
192.168.1.1 - мой домашний роутер
Чтобы ввести в игру реальный интерфейс, нужен vde_pcapplug на нём
(кстати, раз вы явно указываете недефолтный сокет, то vde_pcapplug он
тоже понадобится).
Как и
Вереск wrote:
А можно поподробнее, пошагово как оно работает и как его настроить? Там
точно соблюдены требования из моего первого сообщения?
Все гораздо проще. Вы писали:
Нужно, чтоб виртуальные машины имели адреса той же сети, что и
виртуальная сеть OpenVPN (10.0.0.100, например), виделись
On Thu, Apr 15 2010, Вереск wrote:
1. Есть сервер OpenVPN, физический IP 192.168.1.4 - eth0(потом будет
белый, типа 88.87.93.40), виртуальный tun0 имеет адрес 10.0.0.1
(таковой и предполагается оставить на веки вечные)
[...]
4. Нужно, чтоб виртуальные машины имели адреса той же сети, что и
15.04.2010 10:27, Anton Kovalenko пишет:
On Thu, Apr 15 2010, Вереск wrote:
1. Есть сервер OpenVPN, физический IP 192.168.1.4 - eth0(потом будет
белый, типа 88.87.93.40), виртуальный tun0 имеет адрес 10.0.0.1
(таковой и предполагается оставить на веки вечные)
[...]
4. Нужно,
On Thu, Apr 15 2010, Вереск wrote:
То есть, создать OpenVPN'ом tap0 и, скажем, tap1-3 с помощью vde_tunctl -b
Потом объединить мосты так:
Добавить Мост к реальному интерфейсу brctl addif br0 tap0 - вместо
реального интерфейса задействуем виртуальный, полученный от OpenVPN И
добавляем к
On Thu, Apr 15 2010, Вереск wrote:
Вроде бы так. Правда, я не знаю, может лучше сразу сказать -nic
tap,name=tap0 всем виртуальным машинам, но это имеет резоны не
Я просто не сразу разобрался в отличиях TUN и TAP :-) Пробую теперь
последовать сему совету, о результатах доложусь
На самом деле
On Thu, Apr 15 2010, Вереск wrote:
2. vde_switch использовать не получилось: созданные tap1-2-3 в switch
добавляются без проблем, а вот VPN'овский tap0 говорит, что он
busy. Чем он бизи непонятно. А само решение было бы чрезвычайно
красивым, кстати!
Боюсь, бизи он openvpn'ом, и это резонно.
On Thu, Apr 15 2010, Вереск wrote:
Боюсь, бизи он openvpn'ом, и это резонно. Подключение tap0 через
vde_pcapplug (то есть как сетевого интерфейса, а не как tap-устройства)
должно спасти ситуацию.
Если не сложно, кинь как оно выглядеть должно, я уже запарился кажется
Считаем, что
On Thu, Apr 15 2010, Вереск wrote:
Значит, надо сделать так:
vde_pcapplug tap0 - для VPN
vde_switch -tap tap1 -tap tap2 - для KVM
Я правильно догоняю? Или всё-таки что-то не то гоню?
Правильно, за исключением порядка операций.
vde_switch -tap tap1 -tap tap2 - для KVM
vde_pcapplug tap0 -
On Thu, Apr 15 2010, Вереск wrote:
vde_pcapplug tap0 (от VPN)
vde_plug tap1 (от KVM)
Не ругается. Не работает. IP виртуальной машины (10.0.0.100) остаётся
недоступен. Команды vde_pcapplug вообще нету, только просто plug.
Каким образом не ругается, если команды vde_pcapplug вообще нету?
Вереск wrote:
Возникла такая задумка:
1. Есть сервер OpenVPN, физический IP 192.168.1.4 - eth0(потом будет
белый, типа 88.87.93.40), виртуальный tun0 имеет адрес 10.0.0.1
(таковой и предполагается оставить на веки вечные)
2. Клиент подключается к OpenVPN и получает адрес типа 10.0.0.6
3. На
18 matches
Mail list logo
