Bug 13146

Здесь также только патч на спекфайл.

Нашёл патч на setup-bri. Вы бы не могли описать задачу, которая решается таким
кровавым способом?

Задача автодобовления интерфейса поднятого сторонними средствами (не через
etcnet) в бридж.

У меня это используется для работы с veth* (см.
<http://lists.altlinux.org/pipermail/sysadmins/2007-October/011963.html>):

  Мне понравилось работать с veth через бриджи. Алгоритм примерно такой:

1. Создаём бриджи (с IFUP_PARENTS=no, чтобы мог подниматься при
отсутствии родителей), и все настройки делаем в них.

2. veth загоняем в нужные бриджи.

3. При поднятии VE -- реконфигурируем бриджи (дёргаем setup-bri)

В данном случаи, основная поблема в том, что для пднятия veth ovz использует
свои средства, со скриптами конфигурирования сети (etcnet, в даном случаи) никак
не связанные. Единственное что можно -- вызвать свои скрипты после поднятия.
Нужный функчионал (кроме возможности независимого запуска) в штатном setup-bri
уже содержится.

Вы не поверите, но я вообще не использую виртуализацию. Может, объясните мне по
шагам, как наглядно увидеть решаемую проблему? Инсталляция S4.0 у меня есть.

Полная модель:

1. Поставить ovz ядро, vzctl и модули alterator`а для управления данным
хозяйством (можно и без них, но так проще).

2. Создать тесовую VE, с id`om <veid> (используя любой шаблон).

3. Добавить в данную VE veth интерфейс:

vzctl set <veid> --save --netif_add <ifname>

4. Стартануть VE, если это ещё не сделано.

  На данный момент в сестеме должен быть интерфейс вида veth<veid>.0

5. Создать бридж brd с IFUP_PARENTS=no и HOST='veth<veid>.0' и запустить его...

  Испытания:

1. В данный момент имеем:

а) поднятый интерфейс veth<veid>.0

б) поднятый бридж brd, содержащий в себе veth<veid>.0

2. Останавливаем VE:

vzctl stop <veid>

Посли остановки имеем:

а) фактическое отсутствие интерфейса veth<veid>.0

б) поднятый бридж brd, _не_ содержащий в себе veth<veid>.0

3. Запускаем VE:

vzctl start <veid>

Посли старта имеем:

а) поднятый интерфейс veth<veid>.0

б) поднятый бридж brd, _не_ содержащий в себе veth<veid>.0

3.б -- это то самое, пути решения чего я и предлогаю...

Как понимаю, причина данного поведения в следующем:

1. На уровне etcnet сами интерфейсы veth неописаны ни как: данная система
неможет ими управлять. Простых путей добавить туда эту возможность я невижу --
veth, это внутренняя кухня OVZ, и всё управлене жёско завязанно на vzctl.

2. OVZ, в свою очередь -- неимеет понятия о бриджах, тунелях и пр.. Но оно может
создавать/убивать veth интерфейсы... И vzctl можно обучить выполнять наперёд
заданный скрипт после создания veth интерфейса (можно ли передать имя созданного
veth как параметр данного скрита я непомню, но скорее всего можно).

  Сейчас (в #13147) я решаю данную проблему взаимодействия через скрипт
veth-update_bri (см.
<http://git.altlinux.ru/people/solo/packages/?p=vzctl.git;a=blob;f=scripts/veth-update_bri.in;h=4d3b6c7eca8477ff334f7e4799c4b0f0df1b216f;hb=2ad9a256e21f01deb5802d0475143f1cd5f4091b>),
дёргающий setup-bri для активных бриджей. Но для этого мне нужно, чтобы
setup-bri допускал запуск из стороннего скрипта.

Если есть болие правельный путь -- готов подумать над его реализацией...

Итак, проблема заключается в том, что свежесозданный интерфейс свежесозданного
контейнера приезжает в хост-систему, а там его никто не ждёт. Причём приехать и
уехать он может в любой момент по велению высших сил. Мне кажется, что
предложенная интеграция etcnet и ovz в этой ситуации пойдёт во вред обеим сторонам.
Почему бы не ограничиться тем, что хост-система (в данном случае посредством
etcnet) будет предоставлять готовый мост (набор мостов), а какой-то небольшой
самостоятельный обработчик будет ловить приезжающие и уезжающие контейнеры и
цеплять их куда им положено? Можно такой обработчик поместить в /etc/net/scripts.

(In reply to comment #7)
> Итак, проблема заключается в том, что свежесозданный интерфейс свежесозданного
> контейнера приезжает в хост-систему, а там его никто не ждёт. Причём приехать
> и уехать он может в любой момент по велению высших сил.

  Да.

> Мне кажется, что
> предложенная интеграция etcnet и ovz в этой ситуации пойдёт во вред обеим
> сторонам.

  Прошу пояснить вашу мысль: мне не кажется, что предложенное изменение в
скрипте setup-bri способно повредить etcnet (скорее наоборот: это дополнительный
+, упрощающий интеграцию с другими системами).

> Почему бы не ограничиться тем, что хост-система (в данном случае посредством
> etcnet) будет предоставлять готовый мост (набор мостов), а какой-то небольшой
> самостоятельный обработчик будет ловить приезжающие и уезжающие контейнеры и
> цеплять их куда им положено? Можно такой обработчик поместить в
> /etc/net/scripts.

  Выглядит несовсем логично: такой обработчик должен знать какой интерфейс в
какой мост поместить. И это знание _полностью_ бедет дублировать информацию
которую уже имеет etcnet (в конфигах мостов). При этом всплывут вопросы:

1. Как обрабатывать случаи противоречия данной инфы (и зачем допускать саму
возможность их возникновения)?

2. Как обрабатывать случаи различия состава интерфейсов в мостах в зависимости
от про etcnet`овского профиля?

  Для их решения, придётся слишком жёско привязывать обработчик к etcnet и
дублировать часть etcnet`овской функциональности. Не думаю, что это правельно...

  На мой взгляд, болие логичным выглядит возможность каким либо образом сказать
etcnet что-то типа: "Конфигурация сети изменилась. Действуй."

PS: Может стоит перенести обсуждение в sysadmins@?

Забыл написать, что я предлагаю в /etc/net в конфигурации мостов не перечислять
интерфейсы veth в списке HOST. Дублирования и конфликтов в этом случае не будет.

(In reply to comment #9)
> Забыл написать, что я предлагаю в /etc/net в конфигурации мостов не перечислять
> интерфейсы veth в списке HOST. Дублирования и конфликтов в этом случае не будет.

Как тогда обробатывать зависимость соства объединённых в мост veth от активного
профиля etcnet? (Могу привести примеры ситуаций, когда такое желательно.)

  Дополню:

  Профили -- одна из главнейших фич etcnet, и я весьма хочу, чтобы получившиеся
решение было с ними совместимо. (Хотя предложенное мной -- пока нет.)

Хотелось бы увидеть примеры, да.

Простое преврощение ноута в небольшой сервер сети: несколько профилей
соответствуют нескольким сетям и нескольким наборам запускаемых VE.