13148 2007-10-17 16:33:08 +0400 Прошу добавить возможность поднятия venet0 штатными средствами etcnet 2024-10-28 16:51:13 +0300 1 1 4 Development Sisyphus vzctl unstable all Linux NEW P2 normal --- 1 solo nobody enp evg mike pilot qa-sisyphus oldest_to_newest 56638 0 solo 2007-10-17 16:33:08 +0400 Пошу добавить возможность поднятия 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). 57449 1 solo 2007-11-05 15:02:39 +0300 В 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. 58098 2 ldv 2007-11-13 02:31:20 +0300 Я чего-то, наверное, не понимаю, но 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 58118 3 solo 2007-11-13 13:21:52 +0300 (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? 67339 4 enp 2008-04-02 12:56:05 +0400 > Патч, создающий /etc/net/options.d/80-vz, я не приложу, пусть это делает сам > etcnet. vzctl тут не совсем не виноват, т.к. рестарт сервиса vz при наличии /etc/net/options.d/80-vz не восстанавливает адрес на интерфейсе venet0 67346 5 solo 2008-04-02 13:26:07 +0400 (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 присутствует? 67350 6 enp 2008-04-02 13:39:25 +0400 > > vzctl тут не совсем не виноват, т.к. рестарт сервиса vz при наличии > > /etc/net/options.d/80-vz не восстанавливает адрес на интерфейсе venet0 > > > > /etc/net/ifaces/venet0/ipv4address присутствует? Разумеется, и service network restart восстанавливает адрес 67685 7 solo 2008-04-07 10:06:36 +0400 (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 на старте будет работать. 67686 8 solo 2008-04-07 10:14:23 +0400 (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`м пакетам... 67888 9 solo 2008-04-10 00:04:12 +0400 (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.