+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Proxmox 6.0 переименовывает сетевую карту, и её нельзя использовать., Proxmox Виртуальная Среда

masgo

Guest

05.08.2019 16:25:00

Я только что установил чистую версию proxmox 6.0 на машине, и сетевая карта больше не работает должным образом. Она нормально работала с Proxmox 5.4. Оборудование: сервер HP с 2x гигабитными картами на плате + HP NC364T PCIe (4x гигабитная карта с 2x чипами Intel 82571EB). Проблема в том, что 2 из 4 портов переименовываются при загрузке И они больше не работают в GUI. "Тип сети" отображается как "Неизвестно" для этих портов. В Proxmox 5.4 эти порты отображались как ens0f0 и ens0f1. Что я могу с этим сделать? Код: # dmesg | grep -i eth [1.465004] tg3 0000:03:00.0 eth0: Tigon3 [partno(N/A) rev 5720000] (PCI Express) MAC-адрес 00:fd:45:fc:3e:7c [1.465007] tg3 0000:03:00.0 eth0: прикреплённый PHY 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [1.465009] tg3 0000:03:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [1.465011] tg3 0000:03:00.0 eth0: dma_rwctrl[00000001] dma_mask[64-bit] [1.483040] tg3 0000:03:00.1 eth1: Tigon3 [partno(N/A) rev 5720000] (PCI Express) MAC-адрес 00:fd:45:fc:3e:7d [1.483044] tg3 0000:03:00.1 eth1: прикреплённый PHY 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [1.483046] tg3 0000:03:00.1 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1] [1.483047] tg3 0000:03:00.1 eth1: dma_rwctrl[00000001] dma_mask[64-bit] [1.522370] tg3 0000:03:00.0 eno1: переименован с eth0 [1.531903] tg3 0000:03:00.1 eno2: переименован с eth1 [1.603848] e1000e 0000:09:00.0 eth0: (PCI Express:2.5GT/s:Width x4) 00:1c:c4:47:0e:b1 [1.603851] e1000e 0000:09:00.0 eth0: Intel® PRO/1000 Network Connection [1.603931] e1000e 0000:09:00.0 eth0: MAC: 0, PHY: 4, PBA No: D90972-004 [1.767870] e1000e 0000:09:00.1 eth1: (PCI Express:2.5GT/s:Width x4) 00:1c:c4:47:0e:b0 [1.767873] e1000e 0000:09:00.1 eth1: Intel® PRO/1000 Network Connection [1.767966] e1000e 0000:09:00.1 eth1: MAC: 0, PHY: 4, PBA No: D90972-004 [1.931836] e1000e 0000:0a:00.0 eth2: (PCI Express:2.5GT/s:Width x4) 00:1c:c4:47:0e:b3 [1.931839] e1000e 0000:0a:00.0 eth2: Intel® PRO/1000 Network Connection [1.931919] e1000e 0000:0a:00.0 eth2: MAC: 0, PHY: 4, PBA No: D90972-004 [2.091845] e1000e 0000:0a:00.1 eth3: (PCI Express:2.5GT/s:Width x4) 00:1c:c4:47:0e:b2 [2.091847] e1000e 0000:0a:00.1 eth3: Intel® PRO/1000 Network Connection [2.091927] e1000e 0000:0a:00.1 eth3: MAC: 0, PHY: 4, PBA No: D90972-004 [2.093805] e1000e 0000:0a:00.0 ens1f0: переименован с eth2 [2.131583] e1000e 0000:0a:00.1 ens1f1: переименован с eth3 [2.155876] e1000e 0000:09:00.1 rename5: переименован с eth1 [2.175893] e1000e 0000:09:00.0 rename4: переименован с eth0 Код: # ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP mode DEFAULT group default qlen 1000 link/ether 00:fd:45:fc:3e:7c brd ff:ff:ff:ff:ff:ff 3: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:fd:45:fc:3e:7d brd ff:ff:ff:ff:ff:ff 4: rename4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:1c:c4:47:0e:b1 brd ff:ff:ff:ff:ff:ff 5: rename5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:1c:c4:47:0e:b0 brd ff:ff:ff:ff:ff:ff 6: ens1f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:1c:c4:47:0e:b3 brd ff:ff:ff:ff:ff:ff 7: ens1f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:1c:c4:47:0e:b2 brd ff:ff:ff:ff:ff:ff

jebbam

Guest

08.09.2019 18:56:00

Похоже, что есть несколько способов решить проблему с "постоянными" именами. Правильный способ, видимо, описан в README Debian, вот его отрывок:

Миграция на текущую схему именования сетевых интерфейсов
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Имена интерфейсов должны быть вручную перенесены на новую схему именования перед обновлением до Debian 10 / Ubuntu 18.04 LTS. Если вы полагаетесь на старые имена в настраиваемых записях ifupdown, скриптах брандмауэра или других сетевых конфигурациях, их в конечном итоге нужно будет обновить до новых имен. ВНИМАНИЕ: этот процесс может сделать вашу машину недоступной через ssh. Убедитесь, что у вас есть физический доступ или доступ через последовательную консоль к машине, или способ вернуть старую конфигурацию.

Сначала определите все соответствующие имена сетевых интерфейсов: те, что в /etc/udev/rules.d/70-persistent-net.rules, или если этого файла нет (в случае виртуальных машин), используйте "ip link" или /sys/class/net/. Затем для каждого имени интерфейса выполните команду типа grep -r eth0 /etc, чтобы узнать, где оно используется. Затем на "реальных" компьютерах переименуйте файл в 70-persistent-net.rules.old; альтернативно, если у вас несколько интерфейсов, вместо переименования вы можете закомментировать определенные строки, чтобы изменить одно имя интерфейса за раз. В виртуальных машинах удалите файлы /etc/systemd/network/99-default.link и /etc/systemd/network/50-virtio-kernel-names.link (последний существует только на ВМ, использующих сетевые устройства virtio). Пересоберите initrd с помощью update-initramfs -u и перезагрузите. Тогда ваша система должна получить новое имя (или имена) сетевого интерфейса. Настройте конфигурационные файлы, как указано выше с помощью grep, и протестируйте вашу систему. Повторите для каждого имени сетевого интерфейса, если это необходимо.

jebbam

Guest

08.09.2019 19:16:00

У меня на машине четыре интерфейса, все Intel 82571EB. Два из них обозначены как ens2f0 и ens2f1, и я смог их настроить через веб-интерфейс Proxmox. Другие два интерфейса не отображались в интерфейсе. Их можно было увидеть с помощью `ls /sys/class/net/` и/или `ip link` под названиями "rename3" и "rename4". Чтобы это исправить, я создал файл: /etc/systemd/network/10-eth2.link с следующим содержимым: [Match] MACAddress=00:12:34:56:78:9A [Link] Name=eth2 и перезагрузил систему. После этого он появился в веб-интерфейсе Proxmox. Примечание: это установка Proxmox, добавленная к установке Debian Buster, так что может немного отличаться.

masgo

Guest

08.09.2019 22:51:00

Похоже, у тебя точно такая же проблема, как и у меня, тем более что у вас тот же чип Intel. Так как я установил Proxmox 6 с нуля, а вы использовали Debian, я предполагаю, что ошибка не связана с Proxmox. Но остается вопрос, почему Debian неправильно называет интерфейсы и возвращается к именам "renameX", из-за чего интерфейсы становятся неудобными для использования.

Hartwin

Guest

11.01.2020 06:34:00

Debian не может подумать, что может быть больше одного MAC на порт... эти Интели именно это и делают. Похоже, что Intel просто поставил два сетевых адаптера на одну карточку PCI-X, каждый из них имеет по два сетевых порта. Вот как выглядит такое устройство из ILO4. Раньше все порты имели названия: enp41s0f0, enp41s0f1, enp42s0f0, enp42s0f1. Теперь два из них переименованы: ens8f0, ens8f1 и два 'rename8', 'rename9'. Похоже, раньше использовался путь, а не слот. Адаптер 3 - HP NC364T PCIe Quad Port Gigabit Server Adapter Локация Слот 8 Прошивка 5.12-2 Статус OK Порт MAC-адрес IPv4-адрес IPv6-адрес Статус Команда/Мост Сетевые порты 1 00:24:81:80:9c:2d N/A 2001:16b8:4860:9700:224:81ff:fe80:9c2d/64 fe80::224:81ff:fe80:9 OK N/A 1 00:24:81:80:9c:2f N/A Неизвестно N/A 2 00:24:81:80:9c:2c N/A 2001:16b8:4860:9700:224:81ff:fe80:9c2c/64 fe80::224:81ff:fe80:9 OK N/A 2 00:24:81:80:9c:2e N/A Неизвестно N/A Так как я немного поработал с ifup-скриптами (зная, что название сетевых портов никогда не изменится, как они и обещали), я сделаю решение с /etc/systemd/network/....lnk с старыми именами. Большое спасибо jebbam. [Изменение] Поскольку я хотел немного больше узнать, чем просто несколько строк кода для адаптации... Схема именования по умолчанию немного изменилась. В /lib/systemd/network/99-default.link у них есть упорядоченный список NamePolicy. Первый подходящий выигрывает. Раньше они писали: сохранить базу данных ядра на пути слота. Теперь они пишут: сохранить базу данных ядра на слоте пути. Так что 4 встроенных NIC сохраняют такие же имена, как и раньше. Но не Intel NIC. Они находятся в одном слоте адаптера NC364T. Эти два получат одинаковое имя, так что одно из них получит фиктивное имя. Обратитесь к https://manpages.debian.org/testing/udev/systemd.link.5.en.html для понимания решения jebbam. Меня это немного расстраивает. Это определенно проблема Debian "Buster", потому что они изменили поведение по умолчанию, сломав конфигурацию больших компаний (эти Intel-адаптеры широко распространены). Серьезно? Годы тестирования не выявили этой проблемы?

spirit

Guest

11.01.2020 20:55:00

Спасибо за такой глубокий анализ. Попытаюсь понять, почему в Debian изменили порядок в /lib/systemd/network/99-default.link? Забавно, в Debian Stretch это было NamePolicy=kernel database onboard slot path. Я обновил Proxmox с 5 до 6, у меня все еще NamePolicy=keep kernel database onboard slot path, но в свежем Proxmox 6/Buster NamePolicy=kernel database onboard path slot. Я пообщаюсь с командой Proxmox, возможно, это можно вернуть обратно в пакете Proxmox.

Hartwin

Guest

12.01.2020 10:20:00

Копаясь глубже, собирая информацию, и испытывая раздражение... Похоже, что существует сочетание изменений в Debian (в частности, udev) и Systemd, а возможно, и в пользовательском ядре PVE. Все это становится заметным только в случае, если установлены сетевые карты, такие как Intels. Ваш список изменений в 99-default.link дает скрытый намек: Systemd сначала спрашивает у ядра, есть ли постоянные имена для сетевых интерфейсов. Поскольку в позднем stretch есть правила (/etc/udev/rules.d/70-persistent-net.rules или хотя бы /lib/udev/rules.d/75-persistent-net-generator.rules), ядро ответит с правильным именем. Эти правила udev, похоже, используют ID_NET_NAME_PATH или ID_NET_NAME_ONBOARD, как показано в выводе udevadm test-builtin net_id /sys/class/net/somethinguseful. Поскольку systemd получило имя, оно прекращает переименовывать на этом этапе. Все последующие правила никогда не будут применены. Обновление с 5 на 6 приносит buster и более новую версию systemd. В моем Proxmox 6 версия systemd = 241. https://github.com/systemd/systemd/commits/master/network/99-default.link Они ввели "keep", чтобы не переписывать имена, ранее установленные ядром, udev или чем-то еще. Но правила именования сетевых интерфейсов udev устарели уже много лет. Их использование допустимо, но дистрибутивы могут удалить файлы правил. Proxmox так и сделал. Ни одно из сетевых правил не существует на моей обновленной машине. Так что теперь systemd является единственным хозяином именования для NIC. Ядро не ответит, если его спросят о сетевых именах. 'База данных' не используется, потому что содержит только общую информацию, такую как "ID_OUI_FROM_DATABASE=Hewlett Packard". Имена встроенных сетевых интерфейсов останутся прежними, так как udev запрашивается. Код: root@pve:/sys/class/net# udevadm test-builtin net_id /sys/class/net/eno1
...
Используя стандартную схему именования интерфейсов 'v240'.
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enx9c8e994fac0e
ID_OUI_FROM_DATABASE=Hewlett Packard
ID_NET_NAME_ONBOARD=eno1
ID_NET_LABEL_ONBOARD=enNIC Port 1
ID_NET_NAME_PATH=enp2s0f0 Но теперь становится интересно. Чтобы назвать сеть на PCI-X картах, systemd сначала будет использовать имя на основе слота. Он просто воспользуется ID_NET_NAME_SLOT из ответа udev: Код: root@pve:/sys/class# udevadm test-builtin net_id /sys/class/net/enp42s0f1
...
Используя стандартную схему именования интерфейсов 'v240'.
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enx002481809c2e
ID_OUI_FROM_DATABASE=Hewlett Packard
ID_NET_NAME_PATH=enp42s0f1
ID_NET_NAME_SLOT=ens8f1 Проблема в том, что есть два MAC-адреса на одном слоте. Второй будет "rename3" или что-то похожее: Код: root@pve:/sys/class# udevadm test-builtin net_id /sys/class/net/enp41s0f1
...
Используя стандартную схему именования интерфейсов 'v240'.
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enx002481809c2c
ID_OUI_FROM_DATABASE=Hewlett Packard
ID_NET_NAME_PATH=enp41s0f1
ID_NET_NAME_SLOT=ens8f1 Systemd не считает это ошибкой. Поэтому оно прекращает переименовывать на этом этапе. Поскольку в этом есть некая доля удовольствия обвинять systemd, я бы назвал это ошибкой. Что-то, что претендует на звание настоящего рабочего коня моей системы, должно уметь обнаруживать подобные проблемы. Похоже, кто-то в Proxmox осознавал эту проблему. Они поменяли порядок "слота" и "пути", скрыв этот провал systemd. К сожалению, они не могут изменить это для обновлений на месте, потому что все debian-совместимые элементы (включая systemd) приходят из репозиториев, которые им недоступны. Возможно, следующее обновление systemd отменит это обходное решение, реализовав 99-default от systemd. Это также будет содержать "keep", чтобы не переопределять ручные настройки. Поэтому, если вы что-то спросите у команды Proxmox, пожалуйста, попросите их создать правильный /etc/systemd/network/10-proxmox.link вместо этого. Поскольку этот файл-ссылка просто заменит оригинальный, они могут использовать Код: [Match]
OriginalName=* Я попробую это на своем компьютере, потому что привязка к конкретному MAC нарушит что-то после замены сетевого адаптера. Один URL для завершения (много всего объясняет): https://wiki.debian.org/NetworkInterfaceNames Спасибо, Хартвин.

spirit

Guest

12.01.2020 10:28:00

Привет, я не уверен, что это проблема Debian, думаю, что что-то изменилось в systemd между версиями. Я посмотрел на последние пакеты "udev" для stretch и buster (он предоставляет файл), и в обоих указано "NamePolicy=keep kernel database onboard slot path".

spirit Guest	#9 0 12.01.2020 10:54:00 Извините, я не могу перевести этот текст.

spirit

Guest

#10

12.01.2020 11:18:00

Я также нашел, возможно, связанный отчет о баге в systemd здесь: https://github.com/systemd/systemd/issues/12261. Это действительно кажется не простым, похоже, что изменения в драйверах ядра могут также изменить именование сетевой карты... Также, похоже, можно переопределить политику для каждого драйвера, например: # /etc/systemd/network/10-e1000e-quirks.link
[Match]
Driver=e1000e

[Link]
NamePolicy=по пути или по MAC-адресу, как это работало хорошо с постоянным именем udev /etc/systemd/network/10-ether0.link.
Код:
[Match]
MACAddress=12:34:45:78:90:AB

[Link]
Name=ether0. Мне интересно, не могло бы это последнее быть самым простым вариантом для всех. (Может, что-то в интерфейсе proxmox для настройки такого рода постоянного именования?)

Hartwin

Guest

#11

12.01.2020 11:22:00

Не мог бы ты посмотреть файл /etc/udev/rules.d/70-persistent-net.rules в stretch? Насколько я понимаю, этот файл выполняет ту же функцию, что и файлы .link в systemd, но сообщает системе имена, как имена ядра. В Proxmox 6 (Buster) такого файла нет. Правила в /lib/udev/rules.d, похоже, существуют только для того, чтобы позволить системе оценивать файлы ссылок.

Hartwin

Guest

#12

12.01.2020 12:14:00

... и чтобы добавить еще одно устройство в один из слотов PCI-X, это возможно, но нумерация изменится, сломав 'постоянное' именование. Замена Intel на что-то другое (возможно, Broadcom) вернет нас к "пути слота", снова сломая 'постоянное' именование. Идея заключается в том, чтобы иметь имена для сетевых интерфейсов, которые не меняются, если оборудование нужно заменить. Существуют слишком многие настройки конфигурации, в которых они используются. Насколько я знаю, возможно настроить узел proxmox в виртуализированной среде (вложенные виртуализации). Возможно, MAC-адрес время от времени меняется. Сценарий с заменой сетевых адаптеров такой же, как Driver=..., но даже хуже. Возможно, проще, но не лучше. Это приведет к другому переименованию, даже если адаптер будет заменен на идентичный. Это было решением jebbam в https://forum.proxmox.com/threads/p...ork-card-and-can-not-use-it.56690/post-266253 ... быстрое исправление, чтобы дать время на постоянное решение. На мой взгляд, это бы выглядело так: /etc/systemd/network/10-naming-fix.link Код: [Match]

OriginalName=*

[Link]

NamePolicy=keep kernel database onboard path slot
MACAddressPolicy=persistent

spirit Guest	#13 0 13.01.2020 09:22:00 Я думаю, у меня есть запасной интеллектуальный квадропорт для тестирования, постараюсь проверить это на этой неделе. Держу тебя в курсе.

Fata1W0und

Guest

#14

21.01.2020 16:59:00

Я думаю, что это не ограничивается только сетевыми картами Intel с четырьмя портами. У меня есть Cisco Broadcom 5709 с четырьмя портами с той же проблемой. Я попробовал всё, что смог найти, чтобы заставить все порты работать. Драйверы, прошивка и так далее.

DerGärtner

Guest

#15

31.01.2020 13:12:00

Привет, и спасибо за эту тему! После свежей установки proxmox 6.1-5 у меня тоже возникли проблемы с четырехпортовой сетевой картой Intel. (2 порта работают нормально ens1fX, а 2 порта не работают renameX) Как упоминал jebbam, я создал четыре .link файла в /etc/systemd/network, например 10-ensXfX.link и так далее. Если ввести ip link в консоли:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp11s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
3: enp11s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
4: ens1f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr3 state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
5: ens1f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr2 state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
6: ens2f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr5 state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
7: ens2f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr4 state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
8: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq master vmbr7 state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
9: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq master vmbr6 state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
10: enp0s29f0u2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
11: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
12: vmbr7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
13: vmbr6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
14: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
15: vmbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
16: vmbr3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
17: vmbr4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
18: vmbr5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
19: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr1 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
21: vmbr2v20: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
22: rename22@ens1f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff

Но теперь, если я запускаю виртуальную машину, появляется новая ошибка:
Ошибка: 8021q: VLAN устройство уже существует.
не могу добавить тег vlan 20 к интерфейсу ens1f0
kvm: сетевой скрипт /var/lib/qemu-server/pve-bridge завершился с кодом 512
ЗАДАЧА ОШИБКА: не удалось запустить: QEMU завершился с кодом 1
другая виртуальная машина:
Не удается найти устройство "ens1f1.30"
не могу активировать интерфейс 'ens1f1.30'
kvm: сетевой скрипт /var/lib/qemu-server/pve-bridge завершился с кодом 6400
ЗАДАЧА ОШИБКА: не удалось запустить: QEMU завершился с кодом 1
Что не так с моей настройкой? Можете, пожалуйста, помочь!
pveversion
proxmox-ve: 6.1-2 (работающий ядро: 5.3.13-2-pve)
pve-manager: 6.1-5 (работающая версия: 6.1-5/9bf06119)
pve-kernel-5.3: 6.1-2
pve-kernel-helper: 6.1-2
pve-kernel-5.3.13-2-pve: 5.3.13-2
pve-kernel-5.3.13-1-pve: 5.3.13-1
pve-kernel-5.3.10-1-pve: 5.3.10-1
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.2-pve4
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.13-pve1
libpve-access-control: 6.0-5
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-10
libpve-guest-common-perl: 3.0-3
libpve-http-server-perl: 3.0-3
libpve-storage-perl: 6.1-3
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve3
lxc-pve: 3.2.1-1
lxcfs: 3.0.3-pve60
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.1-2
pve-cluster: 6.1-3
pve-container: 3.0-18
pve-docs: 6.1-3
pve-edk2-firmware: 2.20191127-1
pve-firewall: 4.0-9
pve-firmware: 3.0-4
pve-ha-manager: 3.0-8
pve-i18n: 2.0-3
pve-qemu-kvm: 4.1.1-2
pve-xtermjs: 4.3.0-1
qemu-server: 6.1-4
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.3-pve1

nosuch

Guest

#16

01.03.2020 16:56:00

Не много добавить, но у меня такая же проблема с сетевой картой Intel на четыре порта. Та же самая сетевуха в системе, которая была обновлена с PVE 5 до 6, по-прежнему имеет правильные названия, но на свежей установке 6 у меня два порта называются rename3 и rename6. Я немного новичок, так что, вероятно, что-то упускаю, но хотя бы помогли ли какие-то шаги из этой темы временно решить проблему? Хотелось бы иметь возможность использовать эти два порта, даже если это требует обходного пути.

jebbam Guest	#17 0 01.03.2020 23:49:00 @nosuch Думаю, тебе просто нужно сделать то, что я упомянул в своём посте: https://forum.proxmox.com/threads/p...rk-card-and-can-not-use-it.56690/#post-266253

oz1cw7yymn Guest	#18 0 22.04.2020 16:31:00 Я только что изменил /usr/lib/systemd/network/99-default.link на NamePolicy=path, казалось, что это единственный способ получить последовательные и устойчивые имена сетевых интерфейсов. Текущая реализованная схема политики именования явно несовместима с сетевыми картами с несколькими портами в одном слоте PCI.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры