Пошу добавить возможность поднятия 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).
В 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.
Я чего-то, наверное, не понимаю, но 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
(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?
> Патч, создающий /etc/net/options.d/80-vz, я не приложу, пусть это делает сам > etcnet. vzctl тут не совсем не виноват, т.к. рестарт сервиса vz при наличии /etc/net/options.d/80-vz не восстанавливает адрес на интерфейсе venet0
(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 присутствует?
> > vzctl тут не совсем не виноват, т.к. рестарт сервиса vz при наличии > > /etc/net/options.d/80-vz не восстанавливает адрес на интерфейсе venet0 > > > > /etc/net/ifaces/venet0/ipv4address присутствует? Разумеется, и service network restart восстанавливает адрес
(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 на старте будет работать.
(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`м пакетам...
(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.
