Давно не работал с OpenVZ, взялся снова настраивать, и немного растерялся (не понимаю устройства виртуальной сети). В HN конфигурация такая: eth0 - 10.3.128.50/24 (настроил я) lo - 127.0.0.1 venet0 - без адреса. К контейнере, которому был присвоен ip-адрес 10.3.128.55 (с помощью --ipadd 10.3.128.55): lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:127.0.0.1 P-t-P:127.0.0.1 Bcast:0.0.0.0 Mask:255.255.255.255 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:14 errors:0 dropped:0 overruns:0 frame:0 TX packets:14 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1628 (1.5 KiB) TX bytes:1137 (1.1 KiB) venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.3.128.55 P-t-P:10.3.128.55 Bcast:10.3.128.55 Mask:255.255.255.255 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 таблица маршрутизации (в том же контейнере): # ip route list 192.0.2.0/24 dev venet0 scope host 169.254.0.0/16 dev venet0 scope link default via 192.0.2.1 dev venet0 Шлюз по-умолчанию контейнера (из него же) не пингуется: # ping 192.0.2.1 connect: Invalid argument Тут я что-то растерялся. Откуда взялся адрес 192.0.2.1 (и что это вообще адрес), для чего создан интерфейс venet0:0 и почему venet0 без ip-адреса? Сеть работает, но напрягает отсутствие понимания как оно устроено. Wiki посмотрел, OpenVZ-Users-Guide.pdf тоже, google: "openvz устройство виртуальной сети" смотрел, но не нашел описания устройства виртуальной сети, как это написано в документации к VMWare, например. Кто-нибудь может дать ссылку на толковое описание как оно устроено и как работает? Не разницу между venet и veth, а именно как устроена виртуальная сеть, что за адреса 192.0.2.0/24 и как ходят пакеты? P.S. Еще непонятно, как перебрасываются пакеты из контейнера (наверное, тут Point-to-point используется (пакеты идут через цепочку FORWARD на HN), хотя маска на внешнем интрефейсе /24 и адреса 10.3.128.55 и 10.3.128.50 из одной сети) и как они возвращаются назад (что-то вроде ARP-proxy?)
Здравствуйте, попробую объяснить. venet0 - это такой девайс, в который можно посылать пакеты, и для этого совершенно не обязательно иметь ip адрес на этом девайсе. А то, что пакеты действительно заставляют ходить через venet0, можно посмотреть в выводе команды "ip r l", из которого станет ясно, что все пакеты, предназанчающиеся вашим VE должны идти через venet0. Драйвер этого девайса анализирует каждый приходящий пакет, посколько ip пакет имеет source адрес, то по нему легко можно узнать, в какую VE пакет направляется и передать этот пакет соотвествующим образом. Тут, вроде, все ясно и прозрачно. Таким образом, HN играет роль самого обыкновенного роутера. Если другой компьютер захочет "пообщаться" с вашей VE, то он пошлет arp who-has запрос, который попадет, в частности, и на HN, поскольку подобные запросы являются broadcast запросами; как только такой запрос попадет на HN, она смекает кого хочет видеть сторонняя нода и отвечает вместо VE. Действительно, подобная техника достигается за счет proxy; убедиться в этом можно, посмотрев команду "arp -n" на HN и найдя строчки, относящиеся к поднятым VE. Подобные строчки там появляются благодаря утилите vzctl, которая заносит их в табляцу с помощью команды "ip neigh add proxy $IP_ADDR dev eth0", кстати, routes, которые отображаются командой "ip r l" на HN также есть результат работы vzctl. route по умолчанию, который вы наблдюдаете внутри VE не несет никакой опасности, более того, он полезен, поскольку говорит идти пакету через девайс venet0, который уже внутри себя определит, что пакет идет изнутри VE и отправит согласно routing правилам на HN. Кроме того, маршрут по умолчанию настоятельно рекомедуется иметь внутри VE, поскольку neighbour таблицы VE могут переполниться. Надеюсь, я обстоятельно ответил на интересующие вас вопросы?
> Надеюсь, я обстоятельно ответил на интересующие вас вопросы? спасибо за ответ. Однако хотелось бы манаула с картинками. Все еще непонятно зачем на venet0 в контейнере адрес 127.0.0.1 (такой же, как на loopback), зачем было использовать шлюз по умолчанию 192.0.2.1, а не адрес eth0 в HN, например, и почему сам адрес 192.0.2.1 существует где-то в недрах OpenVZ, где происходит загадочная трансляция. Это может моя личная проблема, но это напоминает Windows. Linux всегда нравился тем, что можно разобраться как оно устроено, а тут какие-то темные моменты...
Здравствуйте еще раз, Quote: Все еще непонятно Не стесняйтесь, спрашивайте, постараюсь ответить. Quote: зачем на venet0 в контейнере адрес 127.0.0.1 (такой же, как на loopback) Этот адрес ставится по историческим причинам, связанным с cовместимости с одной из панелей управления (не помню какой ), то есть ей так удобней управлять VE-шками. Вообще говоря, управление ip адресами на venet интерфейсе должно осуществляться через утилиту vzctl с HN, она должна разбираться, какие адреса ставить на venet, какие удалять и т.д. В противном случае (если настройка была осуществлена изнутри контейнера) после перезагрузки VE конфигурация может смениться, так как она берется из конфигурационного файла контейнера. Разрешите задать встречный вопрос, это мешает вашим приложениям? Почему вы задали этот вопрос? Quote: зачем было использовать шлюз по умолчанию 192.0.2.1, а не адрес eth0 в HN, например, и почему сам адрес 192.0.2.1 существует где-то в недрах OpenVZ, где происходит загадочная трансляция. Мне кажется, вы не уловили суть моего предыдущего поста. venet драйвер не является каким-то особенным сетевым драйвером, он использует то же API, что и стандартный сетевые драйвера. 192.0.2.1 - не загадочный ip адрес, существующий в недрах OpenVZ и тем более, его нет в ядре . Давайте отвлечемся от деталей реализации и рассмотрим эту проблему с общесетевой точки зрения. Допустим у вас есть компьютер, в котором настроено два сетевых интерфейса lo, venet0, причем, как обычно, через интерфейс lo пакеты наружу не отправишь, что естественно. Единственным способ отправить пакеты во внешний мир является интерфейс venet0, который мы знаем, что имеет ти point-to-point, то есть любой пакет, переданный через этот интерфейс всегда пройдет через определенный компьютер (HN в данном случае). Какими должны быть routing правила на рассматриваемом компьютере? Вариантов не ососбо много, а вернее один единственный: если мы хотим коммуницировать с внешним миром, мы должны отправлять пакеты в интерфейс venet0. Теперь вопрос: так ли важен адрес следующего hop'а, указанного в default путе? Грубо говоря, модель сети устроена так, что мы ответственны только за следующий hop (не будем рассматривать всевозможные опции ip пакетов), но мы знаем, что следующий hop - это всегда определенный компьютер. Поэтому стоит ли тратить усилия и узнавать его ip адрес, а вернее ip адрес на каком-то другом физическом интерфейсе, если это не имеет никакого значения с точки зрения составления таблицы маршрутов? Не спорю, вариант составления правил маршрутизации сегодня, может вызвать много вопросов. Если у вас есть рационализаторское предложение, то, конечно же, можете его выразить, обсудим, даже баг забьем для привлечения бОльшего количества обсуждаемых масс.
Quote: Этот адрес ставится по историческим причинам, связанным с cовместимости с одной из панелей управления (не помню какой Smile ), то есть ей так удобней управлять VE-шками. Вообще говоря, управление ip адресами на venet интерфейсе должно осуществляться через утилиту vzctl с HN, она должна разбираться, какие адреса ставить на venet, какие удалять и т.д. В противном случае (если настройка была осуществлена изнутри контейнера) после перезагрузки VE конфигурация может смениться, так как она берется из конфигурационного файла контейнера. Это понятно, просто смущает что один и тот же ip-адрес имеют сразу два интерфейса (в контейнере). Quote: Разрешите задать встречный вопрос, это мешает вашим приложениям? Почему вы задали этот вопрос? Не мешает, просто мне нужно разобраться во внутренностях системы, которой я пользуюсь, и если что-то непонятно, то не могу спокойно работать (может комплекс какой-то). Хочется увидеть что-то вроде http://www.docum.org/docum.org/kptd/ -- после этой картинки (и подобной из iptables-tutorial) iptables стало понять очень просто. В будущем это очень помогает быстро решать проблемы -- когда знаешь как что работает. Quote: Мне кажется, вы не уловили суть моего предыдущего поста. venet драйвер не является каким-то особенным сетевым драйвером, он использует то же API, что и стандартный сетевые драйвера. 192.0.2.1 - не загадочный ip адрес, существующий в недрах OpenVZ и тем более, его нет в ядре . Давайте отвлечемся от деталей реализации и рассмотрим эту проблему с общесетевой точки зрения. Допустим у вас есть компьютер, в котором настроено два сетевых интерфейса lo, venet0, причем, как обычно, через интерфейс lo пакеты наружу не отправишь, что естественно. Единственным способ отправить пакеты во внешний мир является интерфейс venet0, который мы знаем, что имеет тип point-to-point, то есть любой пакет, переданный через этот интерфейс всегда пройдет через определенный компьютер (HN в данном случае). Какими должны быть routing правила на рассматриваемом компьютере? Вариантов не ососбо много, а вернее один единственный: если мы хотим коммуницировать с внешним миром, мы должны отправлять пакеты в интерфейс venet0. Теперь вопрос: так ли важен адрес следующего hop'а, указанного в default путе? Грубо говоря, модель сети устроена так, что мы ответственны только за следующий hop (не будем рассматривать всевозможные опции ip пакетов), но мы знаем, что следующий hop - это всегда определенный компьютер. Поэтому стоит ли тратить усилия и узнавать его ip адрес, а вернее ip адрес на каком-то другом физическом интерфейсе, если это не имеет никакого значения с точки зрения составления таблицы маршрутов? Это примерно понятно, я видел в выводах ifconfig упоминания про peer-to-peer, но непонятно, почему адреса 192.0.2.1 нет ни на одном интерфейсе? В цисках, насколько я помню, для P-t-P соединений с клиентами вместо использования адреса реального интерфейса создается виртуальный адрес, который не деактивируется, если будет отключен Ethetnet, например, (и из-за этого не отвалятся клиенты), но он был виден в настройках, то есть был определенный интерфейс с этим ip. А тут как бы есть ip-адрес, который принадлежит неизвестно какому интерфейсу. Ну и также непонятно, venet0 в HN и контейнерах -- это один интерфейс или два разных? Почему в HN у него нет ip-адреса? И почему в контейнере для него запись "inet addr:127.0.0.1 P-t-P:127.0.0.1" в выводе ifconfig указывает на то, что адрес его соседа 127.0.0.1 -- это адрес loopback в HN или контейнере (или указывает на него самого)? В выводе ifconfig для интерфейса venet0:0 написано "inet addr:10.3.128.55 P-t-P:10.3.128.55", то есть сосед он сам? (Тут может я чего-то не понимаю в выводе iptables, я ppp соединения в Linux не настраивал, могу просто что-то путать, а чтобы посмотреть ничего под рукой нет). Quote: Не спорю, вариант составления правил маршрутизации сегодня, может вызвать много вопросов. Если у вас есть рационализаторское предложение, то, конечно же, можете его выразить, обсудим, даже баг забьем для привлечения бОльшего количества обсуждаемых масс. Надо подумать, если будут мысли -- напишу в этой теме.
Quote: Это примерно понятно, я видел в выводах ifconfig упоминания про peer-to-peer, но непонятно, почему адреса 192.0.2.1 нет ни на одном интерфейсе? В цисках, насколько я помню, для P-t-P соединений с клиентами вместо использования адреса реального интерфейса создается виртуальный адрес, который не деактивируется, если будет отключен Ethetnet, например, (и из-за этого не отвалятся клиенты), но он был виден в настройках, то есть был определенный интерфейс с этим ip. А тут как бы есть ip-адрес, который принадлежит неизвестно какому интерфейсу. Зачем нужна такая логика в OpenVZ? Процесс HN и VE исполняются на ОДНОЙ машине. Пакету не нужно никуда идти, он будет доставлен, как только будет отправлен. Очень похоже на loopback интерфейс. Quote: Ну и также непонятно, venet0 в HN и контейнерах -- это один интерфейс или два разных? Есть единый код, который управляет всей машинерией. Его задачей, в частности, является виртуализация интерфейсов. Поэтому внутри VE и на HN показываются разные результаты. Представляйте себе это как будто есть два списка: интерфейсы внутри VE, интерфейсы на HN. И драйвер добавляет соответсвующие структуры в РАЗНЫЕ списки. Quote: Почему в HN у него нет ip-адреса? Мне кажется вам стоит повнимательней прочесть предыдущие посты.
> Зачем нужна такая логика в OpenVZ? Я не говорил что такая логика, я приводил пример, когда все понятно. По остальному буду думать, спасибо за помощь.
Попробовал перечитать -- все равно черный ящик. Сейчас столкнулся с первой проблемой. Сеть 10.3.128.0/24, шлюз 10.3.128.105, HN 10.3.128.50, контейнер с OpenVPN 10.3.128.55, настроен по wiki, OpenVPN раздает клиентам адреса из сети 17.20.0.0/16, сообщая заодно маршрут на сеть 10.3.128.0/24, VPN работает, с VPN-сервера можно пинговать клиента и наоборот (в том числе адрес 10.3.128.50). На шлюзе по умолчанию добавил маршрут на сеть 172.20.0.0/24: ip route add 172.20.0.0/16 via 10.3.128.55 dev eth1 (интерфейс LAN). При попытке пинговать из сети адрес VPN-клиента получаем: From 10.3.128.50: icmp_seq=1 Redirect Host(New nexthop: 10.3.128.105) HN решила побыть маршрутизатором, ладно, добавим маршрут на неё (что уже вынуждает потом добавлять этот же маршрут на все HN для миграции контейнера): ip route add 172.20.0.0/16 via 10.3.128.55 dev venet0 ip route flush cache делаем пинг на клиента с HN или из сети 10.3.128.0./24 -- в ответ тишина. Куда деваются пакеты и в чем проблема -- вообще никаких мыслей. UPD: Добавил к контейнере с OpenVZ iptables -A FORWARD -j LOG в /var/log/messages ничего, когда пингуешь адрес контейнера и добавляешь правило для INPUT: vpn kernel: IN=venet0 OUT= <2>BUG: recent printk recursion!
На всякий случай таблицы машрутизации: На HN: # ip route list 10.3.128.51 dev venet0 scope link 10.3.128.55 dev venet0 scope link 10.3.128.0/24 dev eth0 proto kernel scope link src 10.3.128.50 169.254.0.0/16 dev eth0 scope link 172.20.0.0/16 via 10.3.128.55 dev venet0 default via 10.3.128.105 dev eth0 В контейнере: 172.20.0.2 dev tun0 proto kernel scope link src 172.20.0.1 192.0.2.0/24 dev venet0 scope host 169.254.0.0/16 dev venet0 scope link 172.20.0.0/16 via 172.20.0.2 dev tun0 default via 192.0.2.1 dev venet0 правила iptables пустые, все разрешено.
Здравствуйте, начнем с конца Quote: в /var/log/messages ничего, когда пингуешь адрес контейнера и добавляешь правило для INPUT: vpn kernel: IN=venet0 OUT= <2>BUG: recent printk recursion! эта бага уже пофикшена http://bugzilla.openvz.org/show_bug.cgi?id=1284 Quote: делаем пинг на клиента с HN или из сети 10.3.128.0./24 -- в ответ тишина. Куда деваются пакеты и в чем проблема -- вообще никаких мыслей. Я думаю, я знаю в чем проблема. venet0 не подойдет, если вы хотите использовать вашу VE как маршрутизатор, поскольку venet0 не пропускает пакеты с source адресом, не равным ip адресу, поставленному на VE. Это сделано намеренно, дабы фильтровать траффик, поступающий внутрь контейнера. Если хотите подобную функциональность - используйте veth в бридж моде (чтобы обойти ненужное прописывание маршрутов на HN).
Спасибо за ответ, а то у меня уже голова закипала, пока пытался понять в чем причина. > эта бага уже пофикшена > http://bugzilla.openvz.org/show_bug.cgi?id=1284 у меня yum check-update не показывает обновлений. > venet0 не подойдет, если вы хотите использовать вашу VE как маршрутизатор, поскольку venet0 не пропускает пакеты с source адресом, не равным ip адресу, поставленному на VE. Это сделано намеренно, дабы фильтровать траффик, поступающий внутрь контейнера. получается как бы незадокументированная фича . Этот момент где-то настраивается? (В плане отключить проверку для опр-го VE с хранением этой настройки в конфиге VE, чтобы автоматом работал при миграции.) Не хотелось бы использовать устройства 2-го уровня, где на 100% работа для 3-го. Про брижд и veth еще не читал, поэтому сказать пока ничего не могу
Quote: у меня yum check-update не показывает обновлений. Оно пофикшено, но ядра еще не зарелижены. Quote: получается как бы незадокументированная фича Прошу прощения, думал, что она задокументирована на страницах http://wiki.openvz.org/Differences_between_venet_and_veth http://wiki.openvz.org/Virtual_network_device однако там упоминается только broadcast траффик. Поэтому можно об этом написать явно. Если есть возможность и желание, можете написать, будем премного благодарны. Quote: Этот момент где-то настраивается? (В плане отключить проверку для опр-го VE с хранением этой настройки в конфиге VE, чтобы автоматом работал при миграции.) Нет, все сделано намеренно. Quote: Не хотелось бы использовать устройства 2-го уровня, где на 100% работа для 3-го. Спорный вопрос. Работа-то для 3-го уровня, но зачем её исполнять на HN, а не внутри VE? И вообще, зачем HN знать что-либо про подсеть 17.20.0.0/16? Quote: Про брижд и veth еще не читал, поэтому сказать пока ничего не могу Wink Читайте, спрашивайте. Чем интереснее будут вопросы (при наличии адекватных ответов), тем более полезным окажется данный тред для других людей.
Уважаемый Марат, еще раз спасибо за прозрачные объяснения. Все понятно, кроме одной детали, а вот venet0:0 зачем? есть же venet0
Quote: Все понятно, кроме одной детали, а вот venet0:0 зачем? есть же venet0 Алиасы (venet0:0, venet0:1, venet0:2 и т.д.) используются для того случая, когда данная VE имеет более одного ip адреса, проставленного с помощью утилиты vzctl.
> Поэтому можно об этом написать явно. Если есть возможность и желание, можете написать, будем премного благодарны. у меня с генерацией английского текста проблемы, лучше Вы > И вообще, зачем HN знать что-либо про подсеть 17.20.0.0/16? ну... может оно и так... Попробую сегодня освоить veth. P.S. По поводу ядра: может как-нибудь почаще релизы делать или беты выкладывать? Я помню, когда в свое время натолкнулся на баг с bonding, хоть мне и прислали ядро с исправлением, но официального ядра с ним я так и не дождался (сменил работу). Кажется Э. Раймонд писал, что лучше почаще делать релизы .
Здравствуйте, Quote: у меня с генерацией английского текста проблемы, лучше Вы Wink По вашей страничке на opennet.ru такого не скажешь . Хорошо, будет свободное время (и не вылетит из головы) - напишу.
> По вашей страничке на opennet.ru такого не скажешь Если это про http://lithium.opennet.ru/publicfile-patch-en.html , то это был многодневный труд с участием translate.ru и знакомых. Я могу попробовать, а Вы исправите если что не так. Сейчас попробовал осилить veth, в wiki (http://wiki.openvz.org/Virtual_Ethernet_device) после добавления девайса (vzctl set 101 --netif_add eth0 --save) написано сделать: 1. Настроить интерфейс на HN: [host-node]# ifconfig veth101.0 0 [host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding [host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp [host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding [host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp 2. настроить ip-адрес интерфейса в CT и шлюз по-умолчанию 3. Настроить маршрут на HN: [host-node]# ip route add 192.168.0.101 dev veth101.0 Насколько я понял, настройки, которые делают эти команды работают до перезагрузки. Чтобы сделать настройки постоянными в случае 2-го пункта нужно исправить стандартные файлы настроек сети в CT (хотя, со шлюзом по умолчанию без ip-адреса я не уверен для CentOS). Пункты 2 и 3 как сделать постоянными с помощью штатных средств не смог догадаться. Попытался создать /etc/sysconfig/vz-scripts/<VEID>.start, но он выполняется в контейнере, а не в HN, а VEID.mount выполняется тогда, когда устройство еще не создано.
Quote: Насколько я понял, настройки, которые делают эти команды работают до перезагрузки. Чтобы сделать настройки постоянными в случае 2-го пункта нужно исправить стандартные файлы настроек сети в CT (хотя, со шлюзом по умолчанию без ip-адреса я не уверен для CentOS). Пункты 2 и 3 как сделать постоянными с помощью штатных средств не смог догадаться. Попытался создать /etc/sysconfig/vz-scripts/<VEID>.start, но он выполняется в контейнере, а не в HN, а VEID.mount выполняется тогда, когда устройство еще не создано. Посмотрите раздел "Making a veth-device persistent", в нем есть ссылка на более старую версию странички, где в разделе "Making a veth-device persistent" описан способ сделать такую конфигурацию постоянной. (замечания в текущей версии не совсем для меня понятны) P.S. (!) Я вам предлагал воспользоваться не такой конфигурацией, а той, что описывается в разделе "Virtual Ethernet devices can be joined in one bridge". То есть единственный бридж, куда входят - физический интерфейс с HN и veth интерфейсы из VE.
> Посмотрите раздел "Making a veth-device persistent", в нем есть ссылка на более старую версию странички, где в разделе "Making a veth-device persistent" описан способ сделать такую конфигурацию постоянной. (замечания в текущей версии не совсем для меня понятны) Если Вы про ссылку http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_de vice&diff=5990&oldid=5989 , то я ходил по ней несколько раз, но не смог понять к чему она была дана в wiki -- не вижу там никакой информации по вопросу. Само устройство остается после перезагрузки, но настройки в proc и маршрут пропадают. > Я вам предлагал воспользоваться не такой конфигурацией, а той, что описывается в разделе "Virtual Ethernet devices can be joined in one bridge". мне казалось что использование veth решит проблему с фильтрацией обратного адреса -- тут же все на втором уровне идет. Бридж наверное не позволит сделать (насколько я могу судить после беглого просмотра) миграцию на лету (ради чего, все собственно и затевается, наряду с быстрым бэкапом и восстановлением). То есть мне в итоге нужно получить систему, позволяющую без дополнительных действий одной-двумя командами переместить контейнер на другую машину и так же быстро/просто восстанавливать его из бэкапа, без дополнительных манипуляций на HN.
По поводу добавления в wiki, фраза в начале статьи (перед "Contents"): "Venet discards ip-packets from container with a source address which is not corresponding to ip-address(es) of the container" будет нормально выглядеть?
http:// wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&am p;diff=5990&oldid=5989#Making_a_veth-device_persistent Там приведен пример скрипта. Quote: По поводу добавления в wiki, фраза в начале статьи (перед "Contents"): "Venet discards ip-packets from container with a source address which is not corresponding to ip-address(es) of the container" Я бы еще упомянул и про обратную сторону, то есть если пакет идет из вне внутрь VE через venet интерфейс, то также происходит отсев. Вы про статью "Сравнение venet и veth" говорите? А вообще, пишите, не бойтесь, если нужно будет - знающие язык люди поправят. Вы и так делает "доброе дело".
Смотрел на разницу между страницами, не догадался вниз пролистать Спасибо за подсказку, но есть несколько неясных моментов: Не нашел в pdf описание принципа работы файла /etc/vz/vznet.conf , скорее всего, он выполняется для всех VE, не приведет ли код выхода 1 в /usr/sbin/vznetaddroute к тому что остальные VE не запустятся, т.к. в pdf написано, что ненулевые коды выходы из скриптов для VE блокируют запуск VE. Сейчас нет второй HN чтобы проверить миграцию, но мне кажется, что этот файл не мигрирует на другую HN... Может быть кроме скриптов /etc/sysconfig/vz-scripts/<VEID>.start можно сделать аналоги, которые будут отрабатываться в контексте HN после старта контейнера. Туда можно было бы поместить и добавление маршрутов, и операции с интерфейсами для контейнера в HN, и загрузку модулей (тот же tun для OpenVPN), что сейчас приходится делать на HN из /etc/sysconfig/modules (в CentOS), что тоже не сильно портабельно, и другие подобные вещи. Ну и соотв-но перемещать эти скрипты при миграции и упаковывать их при бэкапе. Мне кажется что в моем случае проще запустить NAT и venet, добавится возни с логами при разборе полетов, но решение получится легко перемещаемым между HN (что для меня является основным приоритетом). По поводу устройства сети, навеяло чтение документации по OpenVPN. Насколько я понял, они используют tun-модуль и эмулируют P-t-P и Ethernet устройства, причем все получается достаточно понятно. Может взять у них идеи (и часть кода)? То есть нужен venet -- используется аналог tun, нужен veth -- аналог tap. Тут правда дополнительные сложности с виртуализацией... > Вы про статью "Сравнение venet и veth" говорите? нет, про "Virtual network device"
Я вот тоже думаю, что оригинальная документация слишком поверхностно освещает вопросы сети. Мне интересно было бы провести серию экспериментов на базе изучения док и скриптов, но может это будет изобретением велосипеда?
Чтобы данная ветка была полная надо затронуть тему виртуального бриджа. Вот его параметры: virbr0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:1322 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:199580 (194.9 KiB) Моя хост-система CentOS 5.3 Скажите зачем и как создается бридж на хост машине. И причасна ли к этому опенвз? P.S. Изначально стояла ксеновское ядро.
A nice article http://wiki.openvz.org/Virtual_Ethernet_device
У хоста xx.xx.xx.15, для виртуалок адреса с xx.xx.xx.16 по xx.xx.xx.19, вопрос, какой ip адрес нужно назначить venet0? Пока сервер в локалке был, по всей видимости он получал ip адрес по DHCP от роутера (и все отлично работало, пакеты ходили из локалки на виртуалки и обратно), теперь же в стойке, при старте долго думает, и выдает ругань на venet0 (что ip адрес не получен). Шлюз xx.xx.xx.1 upd: venet на хосте присвоил ip xx.xx.xx.15 маску 255.255.255.255, шлюз xx.xx.xx.1, перезапустил сеть, прописал маршрут: route add -host xx.xx.xx.16 gw xx.xx.xx.15 venet0 стал ходить пинг в виртуалку xx.xx.xx.16 и обратно из хоста и виртуалку. Снаружи xx.xx.xx.16 не пингуется.
Для venet0 адрес назначать не нужно совсем - это локальный интерфейс типа raw ip, доступен NE напрямую, не виден другим NE хостам и не нуждается в ip-адресе. Вероятно вам нужна настройка типа бриджа. http://wiki.openvz.org/Virtual_Ethernet_device#Virtual_Ether net_devices_can_be_joined_in_one_bridge Внешние NE хосты должны как-то узнать о существовании ваших VE-хостов. Думаю, что не лишним будет ознакомиться с принципами передачи IP-пакетов по Ethernet-сетям и протоколом ARP. Разово настроить руками - действия такие: 0. Пусть у нас есть сеть 10.0.0.0/24, физический интерфейс eth0 с адресом 10.0.0.1, VE 101 с адресом 10.0.0.101 и маршрутизатор 10.0.0.100. 1. Надо создать ethernet-мост, добавить в него физические интерфейсы и настроить адреса и маршрутизацию. 1.1. Создаем мост и добавляем в него физический интерфейс: HN# brctl addbr br0 HN# brctl addif br0 eth0 1.2. Удалить все адреса (в том числе и inet6) с eth0 и назначить их br0: HN# ip link set dev eth0 down HN# ip address del 10.0.0.1/24 dev eth0 HN# ip -f inet6 address del fe80::280:48ff:fe5d:cb65/64 dev eth0 HN# ip link set dev eth0 up HN# ip address add 10.0.0.1/24 dev br0 HN# ip link set dev br0 up 1.3. Прописываем дефолтный маршрут (он слетел на предыдущем шаге): HN# ip route add default via 10.0.0.100 2. В VE добавляем интерфейс, запускаем (если еще не запущено) VE, добавляем этот интерфейс к мосту и конфигурим сеть VE: HN# vzctl set 101 --netif_add eth0 HN# vzctl start 101 HN# brctl addif br0 veth101.0 HN# vzctl enter 101 VE101# ip address add 10.0.0.101/24 dev eth0 VE101# ip link set dev eth0 up VE101# ip route del default VE101# ip route add default via 10.0.0.100 Если сразу не заработает, подождите пару минут - это связано с работой моста и ARP. Логично, что настроить надо через скрипты конфигурации, чтобы после перезагрузки или настройки восстановились. Касательно включение интерфейса vethXXX.Y в мост, смотрите тут: http://wiki.openvz.org/Virtual_Ethernet_device#syntax_vzctl_ version_.3E_3.0.22 Quote: bridge is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge.