В 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.

Пакет vzctl удалён из Сизифа заданием 361061.1200 (02.11.2024), OpenVZ и venet-интерфейсы больше не существуют. Неактуально.