а в чем прикол? Он на том же PCI подает другой NIC после ребута?

мы ручками не можем внутри ВМ, это клиентские заказы =)

если меняется место но система думает что это чтото другое - это к UDEV

если меняется место но система думает что это чтото другое - это к UDEV

"всякие специфические" - не ваша забота имхо

головняк наш, до установление причины

возьмите их "спефицический" образ и посмотрите на юдев

А какие специфические? ОС?

У меня точно такая же херня на чистой центоси

У меня есть подозрения что это что то в последнем пакете квм)))

а параметры запуска KVM можно посомтреть? ну где проблемы

Такое, кстати, может быть, если что-то пытались сделать с багом https://bugs.launchpad.net/nova/+bug/1751923 , но для старых инстансов не сделали online data migration с fill_virtual_interface_list.

струляет даже там где не обновлялись =)

и даже в virtualbox =)

-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=40 -device virtio-net-pci,netdev=ho stnet0,id=net0,mac=fa:16:3e:76:8e:e2,bus=pci.0,addr=0x3 -netdev tap,fd=41,id=hostnet1,vhost=on,vhostfd=42 -device virtio-net-pci,netde v=hostnet1,id=net1,mac=fa:16:3e:66:da:bb,bus=pci.0,addr=0x4 -netdev tap,fd=43,id=hostnet2,vhost=on,vhostfd=44 -device virtio-net-pci,n etdev=hostnet2,id=net2,mac=fa:16:3e:ac:cd:04,bus=pci.0,addr=0x5 -netdev tap,fd=45,id=hostnet3,vhost=on,vhostfd=46 -device virtio-net-p ci,netdev=hostnet3,id=net3,mac=fa:16:3e:a5:4e:af,bus=pci.0,addr=0x6

струляет даже там где не обновлялись =)

Выглядит то похоже. Если instance_info_cache без фикса обновится и получит информацию из Neutron, то интерфейсы перемешаются, потому что Neutron их возвращает в случайном порядке

ну вот конкретно сейчас случай на площадке. где мы не обновляли стек... там до сих порт либертей пахнет

Коллеги. всем привет. А никто не встречался с такой дичью. что после перезагрузки ВМ у нее могут поменяться местами сетевые адаптеры и ВМ перестает быть доступна по сети. У таких ВМ обычно 2+ адаптера

Привет! А подскажите кто-нибудь юзал эту штуку, я так понимаю, она уже года 2 (даже 5 судя по https://launchpad.net/raksha/) есть в openstack https://wiki.openstack.org/wiki/Raksha

Коллега говорит что в вцентре у них так же Оо

Интерфейсы ещё могут перемешаться после перезагрузки, если они подключались/отключались к запущенному инстансу. Такой вот опенстек. Разработчики новы постоянно пишут, что они не гарантируют порядок подключения volumes из Cinder, раньше и об интерфейсах особо не заботились.

мне тут коллега говорит что вообще мб проблема в либвирте

но це не тока опенстак(

это как настроить ОС Внутри ВМ. Можно намертво прибить, но тогда проблема с размножением)

А почему тогда на вмваре проблема возникает?) Над начать с простых объяснений. Виртуальная машина мигрируется, сетевушки в ней пересоздаются в другом порядке. ssytemd-udevd назначает новые имена потому что с его точки зрения физическое расположение сетевушек изменилось (ну типа оказались подключенными к другим pcie портам)

Она не мигрируется, ее просто выключают

Она не мигрируется, ее просто выключают

Ну, тем не менее. Разницы особой нет, кажется. Корень проблемы может быть действительно в qemu или либвирте, которые хер пойми как подтыкают сетевые интерфейсы. Однако ж, решение проблемы надо искать внутри системы для начала, я думаю. Понять, например, почему система переименовывает интерфейсы.

если линуксу не прибить интерфейсы по MAC например, то при смене слота PCI адаптеру, он получит новое имя. Так udev правило написано по дефолту

а какая разница в каком слоте виртуального PCI адаптер, если он зацеплен на правильный физический интерфейс на гипере и у него не изменился мак-адрес? В гостевой операционке же по мак-адресу можно переименовать интерфейс без проблем?

для этого надо залезть в образ и прибить. а в случае клонирования, править ручками опять

Ну, можно через udev именовать устройства на основе последних 24 бит мак адреса, конечно. Или пойти дальше и полностью включать мак в имя. Тогда никаких проблем)

это все подразумевает доступ внутрь образа. а тут видишь, клиенты не пускают)

Ну тогда как временный вариант сделайте для них пояснение в вики или чо у вас там) Насчет того как временно решить проблему.

Ну и, кстати, как бы я не презирал systemd, но systemd-networkd и netplan как раз и позволяют избежать такой проблемы.