Bug 13148 - Прошу добавить возможность поднятия venet0 штатными средствами etcnet
Summary: Прошу добавить возможность поднятия venet0 штатными средствами etcnet
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: vzctl (show other bugs)
Version: unstable
Hardware: all Linux
: P2 normal
Assignee: Andrew Vasilyev
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-17 16:33 MSD by solo
Modified: 2016-04-21 16:41 MSK (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description solo 2007-10-17 16:33:08 MSD
Пошу добавить возможность поднятия 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 solo 2007-11-05 15:02:39 MSK
В 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 Dmitry V. Levin 2007-11-13 02:31:20 MSK
Я чего-то, наверное, не понимаю, но 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 solo 2007-11-13 13:21:52 MSK
(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 enp 2008-04-02 12:56:05 MSD
> Патч, создающий /etc/net/options.d/80-vz, я не приложу, пусть это делает сам
> etcnet.

vzctl тут не совсем не виноват, т.к. рестарт сервиса vz при наличии
/etc/net/options.d/80-vz не восстанавливает адрес на интерфейсе venet0
Comment 5 solo 2008-04-02 13:26:07 MSD
(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 enp 2008-04-02 13:39:25 MSD
> > vzctl тут не совсем не виноват, т.к. рестарт сервиса vz при наличии
> > /etc/net/options.d/80-vz не восстанавливает адрес на интерфейсе venet0
> > 
> 
>   /etc/net/ifaces/venet0/ipv4address присутствует?

Разумеется, и service network restart восстанавливает адрес
Comment 7 solo 2008-04-07 10:06:36 MSD
(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 solo 2008-04-07 10:14:23 MSD
(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 solo 2008-04-10 00:04:12 MSD
(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.