Bug 13148 - Прошу добавить возможность поднятия venet0 штатными средствами etcnet
: Прошу добавить возможность поднятия venet0 штатными средствами etcnet
Status: NEW
: Sisyphus
(All bugs in Sisyphus/vzctl)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2007-10-17 16:33 by
Modified: 2016-04-21 16:41 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-10-17 16:33:08
Пошу добавить возможность поднятия venet0 штатными средствами etcnet.

Патч сдесь:
<http://git.altlinux.ru/people/solo/packages/?p=vzctl.git;a=commit;h=8d296da311ee46b346f9a0fc12158fa7fd22c869>.

Сдесь
<http://git.altlinux.ru/people/solo/packages/?p=vzctl.git;a=commit;h=459bd2402a8807d5d6d69796dd118c66b3497061>
готовое NMU, добавляющее данный функционал и автоконфигурацию бриджей (#13147).
(Пакет vzctl-3.0.18-alt3.2, ушедшёл в incoming/Daedalus).
------- Comment #1 From 2007-11-05 15:02:39 -------
В incoming/Daedalus ушёл vzctl-3.0.18-alt3.3.src.rpm (см.
http://git.altlinux.ru/people/solo/packages/?p=vzctl.git;a=commit;h=54aea855cd5ff7a545e5fc6e9df4ad187735295c).

Основное изменение -- оторвана зависимость на #13147.

PS: Раскладка по бранчам в 
http://git.altlinux.ru/people/solo/packages/?p=vzctl.git изменена, см.
http://lists.altlinux.org/pipermail/sysadmins/2007-November/012300.html или
http://lists.altlinux.org/pipermail/devel/2007-November/065767.html.
------- Comment #2 From 2007-11-13 02:31:20 -------
Я чего-то, наверное, не понимаю, но venet0 поднимается штатными средствами
etcnet больше года.  Или речь идёт о veth?  В противном случае зачем для
поддержки venet загружать модуль vzethdev?

Патч, создающий /etc/net/options.d/80-vz, я не приложу, пусть это делает сам
etcnet.

2pilot: Просьба прокомментировать этот самый etc/etcnet/80-vz-options в
http://git.altlinux.ru/people/solo/packages/?p=vzctl.git;a=commitdiff;h=3f730127b940b6426f439d41cfea3c4228711edd
------- Comment #3 From 2007-11-13 13:21:52 -------
(In reply to comment #2)
> Я чего-то, наверное, не понимаю, но venet0 поднимается штатными средствами
> etcnet больше года.

  Без данного патча venet0 поднимается через ifup, но не поднимается по service
network start, при начальной загрузке. Причина такого поведения (насколько понял
скрипты etcnet) в отсутствии типа venet в IFGROUP[0].

>  Или речь идёт о veth? В противном случае зачем для
> поддержки venet загружать модуль vzethdev?

  Если один из модулей vzethdev vznetdev не загружен до модуля vznet, то
последующая его загрузка ведёт к ошибке... На практике, это выражается в том,
что после загрузки только vznetdev и vznet интерфейсы veth перестают
подниматься. (Ситуация симметрична: После загрузки только vzethdev и vznet --
перестают подниматься venet.)

> 
> Патч, создающий /etc/net/options.d/80-vz, я не приложу, пусть это делает сам
> etcnet.

  Вешать FR на etcnet?
------- Comment #4 From 2008-04-02 12:56:05 -------
> Патч, создающий /etc/net/options.d/80-vz, я не приложу, пусть это делает сам
> etcnet.

vzctl тут не совсем не виноват, т.к. рестарт сервиса vz при наличии
/etc/net/options.d/80-vz не восстанавливает адрес на интерфейсе venet0
------- Comment #5 From 2008-04-02 13:26:07 -------
(In reply to comment #4)
> > Патч, создающий /etc/net/options.d/80-vz, я не приложу, пусть это делает сам
> > etcnet.
> 
> vzctl тут не совсем не виноват, т.к. рестарт сервиса vz при наличии
> /etc/net/options.d/80-vz не восстанавливает адрес на интерфейсе venet0
> 

  /etc/net/ifaces/venet0/ipv4address присутствует?
------- Comment #6 From 2008-04-02 13:39:25 -------
> > vzctl тут не совсем не виноват, т.к. рестарт сервиса vz при наличии
> > /etc/net/options.d/80-vz не восстанавливает адрес на интерфейсе venet0
> > 
> 
>   /etc/net/ifaces/venet0/ipv4address присутствует?

Разумеется, и service network restart восстанавливает адрес
------- Comment #7 From 2008-04-07 10:06:36 -------
(In reply to comment #4)
> > Патч, создающий /etc/net/options.d/80-vz, я не приложу, пусть это делает сам
> > etcnet.
> 
> vzctl тут не совсем не виноват, т.к. рестарт сервиса vz при наличии
> /etc/net/options.d/80-vz не восстанавливает адрес на интерфейсе venet0
> 

По состоянию на 3.0.22-alt2 -- и не должен. Судя по коду /etc/init.d/vz
(etc/init.d/vz-altlinux.in в девичестве) логика поднятия  venet0 при старте
сервиса следующая (см. функцию setup_net):

1. Если venet0 уже существует -- ничего не делаем, завершаем процедуру. Причём
на этом шаге -- имя интерфейса прописано жёстко, хотя переменная его содержищая
(VZDEV) существует... (Бага?)

2. Если на придыдущем шаге из процедуры setup_net не вышли -- поднимаем $VZDEV с
парметрами по умолчанию, прошитыми в данном коде... (С ip addr 0.0.0.0/0, в
частности.)

  С учётом того, что при останове сервиса $VZDEV _принудительно_ кладётся --
имеем то, что имеем.

  В принцепе, в данную логику можно вклинятся, дёрнув ifup $VZDEV между данными
шагами (с последующий проверкой на поднятие) -- тогда присваивание ip на старте
будет работать.
------- Comment #8 From 2008-04-07 10:14:23 -------
(In reply to comment #2)
...
> 
> Патч, создающий /etc/net/options.d/80-vz, я не приложу, пусть это делает сам
> etcnet.

  Если /etc/net/options.d/80-vz переносить в etcnet, то остальные ovz`овские
скрипты относящиеся к etcnet (etc/etcnet/create-venet.in, в частности) имеет
смысл перенести туда же. Иначе будем иметь поддержку ovz`овских сетей
размазанной по 2`м пакетам...
------- Comment #9 From 2008-04-10 00:04:12 -------
(In reply to comment #7)
> (In reply to comment #4)
> > > Патч, создающий /etc/net/options.d/80-vz, я не приложу, пусть это делает сам
> > > etcnet.
> > 
> > vzctl тут не совсем не виноват, т.к. рестарт сервиса vz при наличии
> > /etc/net/options.d/80-vz не восстанавливает адрес на интерфейсе venet0
> > 
> 
> По состоянию на 3.0.22-alt2 -- и не должен. Судя по коду /etc/init.d/vz
> (etc/init.d/vz-altlinux.in в девичестве) логика поднятия  venet0 при старте
> сервиса следующая (см. функцию setup_net):
> 
...
> 
>   В принцепе, в данную логику можно вклинятся, дёрнув ifup $VZDEV между данными
> шагами (с последующий проверкой на поднятие) -- тогда присваивание ip на старте
> будет работать.

  Так и сделал. У меня -- работает.

PS: vzctl-3.0.22-alt2.1.src.rpm (см.
<http://git.altlinux.org/people/solo/packages/?p=vzctl.git;a=shortlog;h=solo/srpms>)
ушёл в incoming/Daedalus.