25267 2011-03-22 10:39:59 +0300 Перестали создаваться правила для сетевых карточек 2011-03-23 13:26:24 +0300 1 1 4 Development Sisyphus udev-rule-generator unstable all Linux CLOSED NOTABUG P3 major --- 1 boyarsh asy asy mike vitty qa-sisyphus oldest_to_newest 119409 0 boyarsh 2011-03-22 10:39:59 +0300 Предположительно начиная с версии 166, перестали создаваться правила для сетевых карточек: [root@c247 ~]# rpm -q udev-rule-generator udev-rule-generator-166-alt1 [root@c247 ~]# rpm -ql udev-rule-generator | xargs ls -1 ls: невозможно получить доступ к /etc/udev/rules.d/70-persistent-net.rules: Нет такого файла или каталога /lib/udev/rule_generator.functions /lib/udev/rules.d/75-persistent-net-generator.rules /lib/udev/write_net_rules Соответственно, карточки стали меняться именами в самые неподходящие моменты. 119410 1 boyarsh 2011-03-22 10:50:50 +0300 Проблема вот в чём: # ignore KVM virtual interfaces ENV{MATCHADDR}=="52:54:00:*", GOTO="persistent_net_generator_end" Совершенно непонятно за что их так. Kvm-ные интерфейсы могут очень даже смотреть в реальные сети (да если даже бы и не в реальные) и даже DHCP в них раздавать. Я считаю, что надо уравнять их в правах с обычными и записывать в persistent-rules. Если бы я использовал XEN и vmware, вероятно, у меня возникли бы точно такие же мысли по поводу их виртуальных интерфейсов. Возможно, имеет смысл повесить запоминаемость виртуальных интерфейсов на control, но лично я считаю, что, поскольку виртуализация используется в production, виртуальные интерфейсы точно также не должны меняться именами. 119411 2 vitty 2011-03-22 10:58:36 +0300 Смысл в игноре KVM/Xen/Vmware есть. Обычно у виртуальных машин всего один интерфейс, но при этом его MAC может меняться (копирование машин, миграции...) При этом хочется, чтобы каждая новая машина умела настроенный обычно по DHCP eth0 (а не ethN+1 без настроек). 119412 3 shrek 2011-03-22 11:03:36 +0300 KVM (и видимо остальные VM) при каждой загрузке выдают случайный MAC (если он не указан явно). если убрать это исключение, то при каждой загрузке будет плодиться новый интерфейс и с помощью того же etcnet хрен когда ты его настроишь. вывод: указывать MAC явно, причем отличный от зарезервированного для VM'ов 119415 4 boyarsh 2011-03-22 11:10:26 +0300 Да, всё неоднозначно :( libvirt-то выдаёт постоянные адреса. Да, видимо решение действительно в том, чтоб прибивать неигнорируемые MAC адреса . Спасибо! Извини, что дёрнул, но когда я с утра случайно обнаружил, что тестовая виртуалка раздаёт DHCP в офисную сеть потому, что у неё прыгнули интерфейсы, ощущение было из серии "ААА!! всё разломалось!!" 119416 5 boyarsh 2011-03-22 11:11:13 +0300 вообще, к хорошему (к тому, что интерфейсы не прыгают) быстро привыкаешь ;) 119440 6 mike 2011-03-23 13:26:24 +0300 (In reply to comment #4) > Извини, что дёрнул, но когда я с утра случайно обнаружил, что тестовая > виртуалка раздаёт DHCP в офисную сеть потому, что у неё прыгнули интерфейсы, > ощущение было из серии "ААА!! всё разломалось!!" Тестовые виртуалки лучше через NAT или ещё как, но не пускать бродкастить в сеть, эт факт. А генерация для нормальных карточек работает, как раз вчера в это игрался именно на 166.