Re: Помогите разобраться с мостами для KVM
On Sat, Apr 17 2010, Вереск wrote: Забавное наблюдение: при использовании vde виртуалка видится отовсюду, кроме, собсно, хоста :-) Ну или я опять недоглядел маршруты. Кроме, собсно, хоста это к vde_pcapplug (точнее, к её отсутствию). Проверьте: ip route get ип.вир.туал.ки должен возвращать правильный интерфейс (тот, что в vde_pcapplug) и _не иметь_ указания на гейт (via x.x.x.x). Или можно для операций с хостом сделать отдельный tap (vde_switch -tap tap2) и сбриджить его со всем остальным (как я понял, с eth0 в вашем тестовом варианте и с openvpn'овским tap0 - в окончательном) [помните примечание про поднятые бриджи]. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
А можно поподробнее, пошагово как оно работает и как его настроить? Там точно соблюдены требования из моего первого сообщения? А что вам мешает и из виртуальной машины запустить openvpn клиент, соединиться с сервером и получить желаемый ip ? У меня все kvm машины соединяются с openvpn при загрузке - только через эту сеть с ними по ssh и общаюсь. Конфиг: http://www.mail-archive.com/debian-russian@lists.debian.org/msg104514.html -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bc81290.7050...@mail.ru
Re: Помогите разобраться с мостами для KVM
On Fri, Apr 16 2010, Вереск wrote: Что-то и где-то я явно не уловил. 1. Про -net vde даже на офсайте написана исчерпывающая информация: vde another option is using vde (virtual distributed ethernet). -net vde[,vlan=n][,name=name][,sock=socketpath][,port=n][,group=groupname][,mode=octalmode] Connect VLAN n to PORT n of a vde switch running on host and listening for incoming connections on socketpath. Use GROUP groupname and MODE octalmode to change default ownership and permissions for communication port. This option is available only if QEMU has been compiled with vde support enabled. Example: # launch vde switch vde_switch -F -sock /tmp/myswitch # launch QEMU instance qemu linux.img -net nic -net vde,sock=/tmp/myswitch 2. Про vde_pcapplug - не нахожу. У меня обычный Debian Lenny. Пробовал искать во всех репозитариях. Но данную программу не поставляют до версии 2.2.3, то есть придётся качать для testing. Надо попробовать обойтись, значит. Если хочется обойтись, тогда либо бридж, как в начале говорили, либо vpn-клиент внутри VM, как советуют в соседнем треде (да, я перечитал первое сообщение, всё соответствует. Клиент openvpn под винду есть). Ещё по итогам перечитывания - обнаружил, что вы не поднимаете br0 (ifconfig должен показывать все задействованные интерфейсы без -a; соответственно, тем из них, у которых нет адресов, надо сделать ifconfig $IFACE 0.0.0.0 up, либо ip link set up $IFACE). -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
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. Так что этот путь лучше оставить в покое, если не хотите обновляться или бэкпортить. # launch vde switch vde_switch -F -sock /tmp/myswitch # launch QEMU instance qemu linux.img -net nic -net vde,sock=/tmp/myswitch И как это должно выглядеть со стороны хоста и клиента? Кажется, постижимый для меня уровень абстракций уже пройден :-) Наверное, это не важно (если обновляться не будете). -net nic создаёт сетевую карту в VM, а параллельное ему -net vde (как и все остальные фиговины вроде -net tap) втыкает эту карту в свитч. Список -net nic'ов сопоставляется поэлементно списку -net всегоОстального (но это вы читали, наверное). Если хочется обойтись, тогда либо бридж, как в начале говорили, либо vpn-клиент внутри VM, как советуют в соседнем треде (да, я перечитал первое сообщение, всё соответствует. Клиент openvpn под винду есть). То есть надо поднять просто сеть через br0 и прицепиться уже из гостя к внешнему IP хозяина? Некрасиво получается: фактически внутренний трафик VPN'a Гость-Хост начинает бегать через внешнюю сеть. А ведь в дальнейшем это будет некоторый белый IP. Кажется, тут кроется какая-то проблема. Это да, что некрасиво то некрасиво, поэтому в общем-то я и не предложил подобного (нужный уровень отчаяния ещё не достигнут). Ещё по итогам перечитывания - обнаружил, что вы не поднимаете br0 (ifconfig должен показывать все задействованные интерфейсы без -a; О! Ценное замечание, надо будет опробовать, может что-то и добьюсь. Уточню: любой интерфейс, который не UP, работать не должен. Т.е. какое бы решение не выбрали, проверяйте, что все задействованные интерфейсы подняты, даже если адреса на них нет. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
On Fri, Apr 16 2010, Вереск wrote: Наверное, это не важно (если обновляться не будете). -net nic создаёт сетевую карту в VM, а параллельное ему -net vde (как и все остальные фиговины вроде -net tap) втыкает эту карту в свитч. Список -net nic'ов сопоставляется поэлементно списку -net всегоОстального (но это вы читали, наверное). Думаю, важно :-) Раз уж забэкпортился. После сопоставления этот vde как выглядит? В виртуальной машине какой адрес назначится? Куда пойдут пакеты и будет ли видно снаружи? Какой IP-адрес назначится в виртуальной машине -- это _исключительно_ забота ОС внутри виртуальной машины; kvm, как и прочие машинные виртуализаторы, могут влиять на это только косвенно (например, при -net user нужный адрес выдаётся по DHCP). В случае -net vde, как и во многих других, kvm своего DHCP-сервера не заводит -- так что проще всего настраивать ОС внутри ВМ на статический адрес. MAC-адрес виртуальной сетевой карты можно указать в -net nic (впрочем, если не указывать, там будет какое-то резонное умолчание; мне ни разу указывать не приходилось, ибо и так всё работало). При использовании vde_switch пакеты идут в процесс vde_switch, а этот процесс их раздаёт кому интересно -- например, если пакет на FF:FF:FF:FF:FF:FF (ethernet broadcast), vde_switch раздаст его на остальные VM (-net vde), на vde_pcapplug'и (которые отправят его в свой реальный интерфейс), ну и вообще любому клиенту (vde_switch'у не обязательно знать, что за тварь такая к нему подключилась). Если dst mac указан явно, vde_switch использует таблицу port-mac, чтобы лишний раз не множить трафик - точно так же, как и обычный свитч. Vde_pcapplug также ловит чужие пакеты со своего интерфейса (любые) и отправляет их vde_switch'у. Что с ними делает vde_switch, написано в предыдущем абзаце. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
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 /home/veresk/soft/kvm/NetKVM-and-viostor.iso Выдаёт такую гадость: pci_add_option_rom: failed to find romfile pxe-virtio.bin ОС запускается, дал ей IP из локалки 192.168.1.15 и прописал GW как у всех, то есть 192.168.1.1 По нулям. Я наверное что-то не доделал? Между кем и кем проверяете сеть? Чтобы ввести в игру реальный интерфейс, нужен vde_pcapplug на нём (кстати, раз вы явно указываете недефолтный сокет, то vde_pcapplug он тоже понадобится). Пинги между виртуальными машинами, воткнутыми в один и тот же vde_switch (т.е. с одним и тем же sock=) должны ходить без участия реальных интерфейсов хоста. Возможно, вам будет удобно начать именно с этого. Насчёт ошибки про pci_add_option_rom (относящейся явно к -net nic,model=virtio) -- не уверен: она может быть как фатальной, так и нет, но если ОС ВМ показывает наличие сетевухи, скорее всего это просто предупреждение. Впрочем, я бы попробовал просто -net nic (подразумевается model=e1000, или как минимум что-то более-менее всегда работающее) -- чтобы не осложнять ситуацию. А когда заработает, можно с virtio разбираться отдельно. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
On Fri, Apr 16 2010, Anton Kovalenko wrote: Пинги между виртуальными машинами, воткнутыми в один и тот же vde_switch (т.е. с одним и тем же sock=) должны ходить без участия реальных интерфейсов хоста. Возможно, вам будет удобно начать именно с этого. Кстати, ещё одна неоговорённая деталь: виндовый файрволл, который внутри виртуальных машин. Он способен помешать им пинговаться, как между собою, так и с хоста; мешать друг на друга заходить по пути UNC \\i.p.addr.ess он _по умолчанию_ не должен, но если его настраивали -- может (или если не биндили соответствующие службы на интерфейс). В общем, виндофайрволл я бы для начала выключил, и проверял бы пинги. Правда, если у вас до того с этими машинами уже работал одиночный -net tap для связи с хостом (и пинги ходили), это свидетельство того, что с файрволлом проблем нет. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
On Fri, Apr 16 2010, Вереск wrote: 192.168.1.5 - реальный интерфейс хозяина - 0 реакции 192.168.1.1 - мой домашний роутер Чтобы ввести в игру реальный интерфейс, нужен vde_pcapplug на нём (кстати, раз вы явно указываете недефолтный сокет, то vde_pcapplug он тоже понадобится). Как и куда понадобится? У меня пока что второй виртуалки нет, OpenVPN тоже пока погасил. Работаю на ноутбуке (eth0 192.168.1.5) и просто пытаюсь прикрутить сеть в виртуалку. Вот как ввести потом виртуальную машину в VPN-сеть, это надо продолжать париться. Когда вы читали man vde_pcapplug (? :-), вам наверняка запомнилось, что у него есть опция --sock=, на случай, если вас не устраивает общее умолчание для всего vde* семейства (/tmp/vde.ctl). Наверное, явно указывать /tmp/mys3 вы стали как раз потому, что оно вас не устраивает. Для подключения VM к реальной машине через vde_switch надо: - запустить vde_switch (включаем воображение; я подвёл питание к этой коробочке, и на ней загорелась лампочка -- ага, работает). - запустить vde_pcapplug --sock=/tmp/mys3 eth0 (я подключил коробочку с лампочками к моей замечательно работающей локальной сети, где до этого все пинги ходили и было полное счастье) - запустить kvm с указанными опциями (я включил новый компьютер, предварительно поставив туда сетевую карту (-net nic) и соединив её с той же самой сияющей коробочкой (-net vde,sock=/tmp/mys3)). -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
Вереск wrote: А можно поподробнее, пошагово как оно работает и как его настроить? Там точно соблюдены требования из моего первого сообщения? Все гораздо проще. Вы писали: Нужно, чтоб виртуальные машины имели адреса той же сети, что и виртуальная сеть OpenVPN (10.0.0.100, например), виделись подключёнными клиентами и между собой. в этом случае вам не нужно никаких мостов и не надо знать какой IP и на каком континенте получила KVM. Достаточно из-под kvm запустить openvpn клиент. Настраивать там особенно нечего. Конфиги по ссылке - рабочие. Если будет безпарольная авторизация по сертификатам - содиняться будет автоматом при загрузке. Даже vnc не нужен будет. -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hq9j3t$vk...@dough.gmane.org
Re: Помогите разобраться с мостами для KVM
On Thu, Apr 15 2010, Вереск wrote: 1. Есть сервер OpenVPN, физический IP 192.168.1.4 - eth0(потом будет белый, типа 88.87.93.40), виртуальный tun0 имеет адрес 10.0.0.1 (таковой и предполагается оставить на веки вечные) [...] 4. Нужно, чтоб виртуальные машины имели адреса той же сети, что и виртуальная сеть OpenVPN (10.0.0.100, например), виделись подключёнными клиентами и между собой. OpenVPN перевести на tap0 вместо tun0. Потом соединить локальные tap0 с интерфейсами виртуальных машин в мост (bridge-utils). Дело в том, что tun - это соединение точка-точка, в отличие от tap, который «виртуальный ethernet». Хотя за счёт проксирования arp и можно создать иллюзию «подсети», в которую входят машины по сторонам tun, эта иллюзия будет неполна: broadcast'ы не ходят. Можно будет поставить bcrelay или ещё что-то, чтобы добавить иллюзию хождения broadcast'ов. Но с учётом того, что openvpn умеет и tap, в котором всё _уже_ хорошо, лучше воспользоваться tap. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
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. Нужно, чтоб виртуальные машины имели адреса той же сети, что и виртуальная сеть OpenVPN (10.0.0.100, например), виделись подключёнными клиентами и между собой. OpenVPN перевести на tap0 вместо tun0. Потом соединить локальные tap0 с интерфейсами виртуальных машин в мост (bridge-utils). Дело в том, что tun - это соединение точка-точка, в отличие от tap, который «виртуальный ethernet». Хотя за счёт проксирования arp и можно создать иллюзию «подсети», в которую входят машины по сторонам tun, эта иллюзия будет неполна: broadcast'ы не ходят. Можно будет поставить bcrelay или ещё что-то, чтобы добавить иллюзию хождения broadcast'ов. Но с учётом того, что openvpn умеет и tap, в котором всё _уже_ хорошо, лучше воспользоваться tap. То есть, создать OpenVPN'ом tap0 и, скажем, tap1-3 с помощью *vde_tunctl -b Потом объединить мосты так: *Добавить Мост к реальному интерфейсу *brctl addif br0 tap0* - вместо реального интерфейса задействуем виртуальный, полученный от OpenVPN И добавляем к мосту виртуальные машины *brctl addif br0 tap1-2-3-4 Правильно понял? ЗЫ. Простите за переспрос, запутался уже радикально, а чтоб проверить надо опять хард переставлять - экспериментальной машинки нема. *
Re: Помогите разобраться с мостами для KVM
On Thu, Apr 15 2010, Вереск wrote: То есть, создать OpenVPN'ом tap0 и, скажем, tap1-3 с помощью vde_tunctl -b Потом объединить мосты так: Добавить Мост к реальному интерфейсу brctl addif br0 tap0 - вместо реального интерфейса задействуем виртуальный, полученный от OpenVPN И добавляем к мосту виртуальные машины brctl addif br0 tap1-2-3-4 Правильно понял? Вроде бы так. Правда, я не знаю, может лучше сразу сказать -nic tap,name=tap0 всем виртуальным машинам, но это имеет резоны не заработать. Одно знаю точно: пытаться соорудить подсеть (броадкастный домен) из tun вы будете гораздо дольше :) -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
On Thu, Apr 15 2010, Вереск wrote: Вроде бы так. Правда, я не знаю, может лучше сразу сказать -nic tap,name=tap0 всем виртуальным машинам, но это имеет резоны не Я просто не сразу разобрался в отличиях TUN и TAP :-) Пробую теперь последовать сему совету, о результатах доложусь На самом деле я вспомнил ещё вариант, который может быть удобнее и вообще лучше. Всё как было (настраиваем openvpn на tap0, у каждой VM свой tap), но потом запускаем vde_switch -tap tap0 -tap tap1 -tap tap2 ..., а он уже занимается чем положено, без brctl и br0. (Всё-таки хорошая метафора - великая вещь. Зная, что такое железный свитч, работать с vde_switch очень удобно). -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
On Thu, Apr 15 2010, Вереск wrote: 2. vde_switch использовать не получилось: созданные tap1-2-3 в switch добавляются без проблем, а вот VPN'овский tap0 говорит, что он busy. Чем он бизи непонятно. А само решение было бы чрезвычайно красивым, кстати! Боюсь, бизи он openvpn'ом, и это резонно. Подключение tap0 через vde_pcapplug (то есть как сетевого интерфейса, а не как tap-устройства) должно спасти ситуацию. Ещё насчёт tun - прочтите совет Виктора Вагнера про --topology, хотя у меня ощущение, что вам tap всё равно больше подходит (а на tap --topology не действует). Я пропустил момент, когда эта опция появилась, а она полезная. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
On Thu, Apr 15 2010, Вереск wrote: Боюсь, бизи он openvpn'ом, и это резонно. Подключение tap0 через vde_pcapplug (то есть как сетевого интерфейса, а не как tap-устройства) должно спасти ситуацию. Если не сложно, кинь как оно выглядеть должно, я уже запарился кажется Считаем, что vde_switch'у сокет не указан. Тогда vde_pcapplug tap0 должно быть достаточно. :-) Кстати, а почему если занят tap0 и как tap добавляться не желает, то считаешь, что добавится как физ устройство? Потому что работать с raw sockets по обоим направлениям может куча приложений одновременно, в чём я не раз убеждался - а именно это pcap и делает. Открыть же подслушивающую/посылающую сторону tap0, как мы видим из ваших приключений, может только одно приложение (я это подозревал, но уверен не был) -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
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 - для VPN Т.е. сначала делаем свитч, а потом втыкаем туда tap0; а наоборот не получится. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
On Thu, Apr 15 2010, Вереск wrote: vde_pcapplug tap0 (от VPN) vde_plug tap1 (от KVM) Не ругается. Не работает. IP виртуальной машины (10.0.0.100) остаётся недоступен. Команды vde_pcapplug вообще нету, только просто plug. Каким образом не ругается, если команды vde_pcapplug вообще нету? Пакет vde2 стоит? Работать в таком виде и не должно: vde_plug tap1 означает приконнектить stdin/out к сокету tap1/vde.ctl. Но и я не подумал в очередной раз: VM и vde_switch будут конфликтовать за tap'ы. В вашей версии kvm -net vde есть? Тогда попробуйте использовать его (т.е. tap для VM будут не нужны, а для tap0 нужен vde_pcapplug, который надо всё-таки раздобыть). -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Помогите разобраться с мостами для KVM
Вереск 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. На той же машине запущен KVM с виртуальной WinXP... А что вам мешает и из виртуальной машины запустить openvpn клиент, соединиться с сервером и получить желаемый ip ? У меня все kvm машины соединяются с openvpn при загрузке - только через эту сеть с ними по ssh и общаюсь. Конфиг: http://www.mail-archive.com/debian-russian@lists.debian.org/msg104514.html -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hq80qe$gh...@dough.gmane.org
