ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Прошу добавить возможность поднятия venet0 штатными средствами etcnet | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | solo <solo> |
| Component: | vzctl | Assignee: | Nobody's working on this, feel free to take it <nobody> |
| Status: | NEW --- | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P2 | CC: | enp, evg, mike, pilot |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
|
Description
solo
2007-10-17 16:33:08 MSD
В 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. |
