Аспро: ЛайтШоп [тема: MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP]

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Fri, 13 Jun 2025 11:21:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
О блин! Сначала особая структура файлов, чтобы он мог распознавать ISO, образы и так далее, а теперь вот это. Proxmox сегодня никак не радует. В любом случае, хотя бы могу выйти, не заходя (переносить виртуальные машины). Хотя, думаю, загляну сюда лет через год… Кажется, читал, что этому уже три года? Вернусь при следующем крупном обновлении.
13.06.2025 11:21:00, senseivita.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Tue, 06 Aug 2024 17:51:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Привет, не мог бы ты объяснить, как ты это сделал? Спасибо!
06.08.2024 17:51:00, aleixsr.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Sat, 23 Dec 2023 11:47:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я как раз столкнулся с таким же вопросом. Сейчас я использую виртуализацию KVM с QEMU и хочу перейти на Proxmox. Однако меня удивляет, что MACVTAP не поддерживается нативно. Прошло уже 3 года с момента начала этой темы, и всё ещё единственный способ настроить MACVTAP — это вручную править конфигурацию каждой виртуальной машины?
23.12.2023 11:47:00, flunkyball.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Fri, 09 Sep 2022 18:27:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Ты исправил уже проблему, что аргументы нельзя использовать в linux-команде типа 10<>/dev/tap$(cat /sys/class/net/mvt102/ifindex) при работе с macvtap? @wrobelda
09.09.2022 18:27:00, skill7899.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Fri, 02 Sep 2022 15:16:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Окей, разобрался, скоро выложу исправления.
02.09.2022 15:16:00, wrobelda.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Tue, 30 Aug 2022 17:17:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
@ctr Думаю, исправлять проблему с `args` всё равно стоит, да?
30.08.2022 17:17:00, wrobelda.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Tue, 30 Aug 2022 01:50:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Мне пришлось потратить время на изучение вопроса, но оказалось, что и MACVTAP в режиме Passtru, и IPVLAN будут решениями моей проблемы, описанной здесь: https://forum.proxmox.com/threads/t...arently-relay-to-host-nic.113600/#post-490741. Так что, если есть один повод добавить поддержку этого, то это возможность использовать Proxmox как гипервизор уровня L1 и запускать файрвол во VM уровня L2, если хостинг не позволяет несколько MAC-адресов на один L1 VF.

P.S. Теперь я понимаю, что ты тоже упоминал это как известную проблему, которую это должно решить.
30.08.2022 01:50:00, wrobelda.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Sun, 12 Dec 2021 16:56:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Ещё одно преимущество macvtap (если вышеперечисленного недостаточно) — возможность передавать VF сетевого устройства (или всё устройство целиком) без настоящего pci-passthrough, что даёт возможность миграции. Подробности смотрите здесь: https://access.redhat.com/documenta...Physical_interface_delivery_modes-passthrough и https://wenchma.github.io/2016/09/07/macvtap-deep-dive.html#title5. Надеюсь, этих весомых причин достаточно, чтобы возможность использования macvtap/ipvtap в Proxmox улучшила опыт пользователей. @dietmar, если ты в целом готов это принять, я мог бы изучить вопрос и подготовить PR.
12.12.2021 16:56:00, ctr.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Sun, 12 Dec 2021 16:10:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Насколько я понимаю, единственное, что мешает полузависимой работе в proxmox — это то, что в qm.conf аргументы "-args" берутся в кавычки. Из-за этого создаётся ошибка при создании файлового дескриптора (например, <>/dev/tap31 в приведённом примере). Однако дескрипторы, переданные из командной строки при вызове qm, доходят до kvm, и поэтому запись в qm.conf работает у меня так:

Код:
args: -netdev 'type=tap,fd=10,id=net0,vhost=on' -device 'virtio-net-pci,mac=xx:xx:xx:xx:xx:xx,netdev=net0,bus=pci.0,addr=0x12,id=net0'

Запускаю виртуальную машину командой:

Bash:
qm start vmid 10<>/dev/tapid

В приведённом примере (если tap — это "31", его можно узнать по /sys/class/net//ifindex):

Bash:
qm start vmid 10<>/dev/tap31

Насколько я понимаю, номер файлового дескриптора можно взять любой, главное — чтобы он совпадал и в qm.conf, и при создании дескриптора в shell. Лучше не использовать 0, 1 или 2, видел, что иногда берут "3".
12.12.2021 16:10:00, ctr.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Wed, 14 May 2025 20:42:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Недавно я настроил виртуальную машину с Mikrotik CHR и заметил, что нагрузка при использовании моста + virtio (в моём случае Open vSwitch) была неприемлемой даже при скорости около 2,5 Гбит/с. Тесты показали, что загрузка процессора при конфигурации macvtap вместо моста + tap была значительно ниже. Из-за невозможности настроить macvtap (нельзя передать дескрипторы tap-файлов в конфигурации ВМ) мне пришлось использовать passthrough сетевых карт, но это тоже не идеальное решение.
14.05.2025 20:42:00, kam821.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Sat, 11 Dec 2021 17:48:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я поигрался с ipvtap и вижу здесь реальное преимущество по сравнению с обычным мостовым подключением: ВМ (и контейнерам, к слову) не нужна уникальная MAC-адрес, они используют MAC физического интерфейса. Это проблема для многих хостов (например, у Hetzner разрешен только один MAC, даже если у тебя есть IPv6 /56). Связь между ВМ тоже может быть значительно быстрее, чем в классическом мосте и l3-режиме (ещё не проверял), и, судя по руководствам по macvtap/ipvtap, масштабироваться это должно лучше. Однако, похоже, Proxmox не принимает нужный синтаксис, даже если вручную редактировать qm.conf и использовать "-args". Но на командной строке это работает. Например, возьми любимую ВМ и посмотри полный вызов kvm (ps axwww тебе в помощь). Потом замени сеть на что-то вроде: -netdev type=tap,fd=31,id=net0,vhost=on,vhostfd=4 31<>/dev/tap31 4<>/dev/vhost-net -device virtio-net-pci,mac=34:97:f6:5b:11:55,netdev=net0,bus=pci.0,addr=0x12,id=net0 где "/dev/tap31" — это символический узел, созданный при создании vtap, а MAC-адрес совпадает с MAC физического интерфейса. Перед этим, конечно, нужно создать и поднять интерфейс vtap. У меня сработало так: ip link set <имя-физического-интерфейса> name ipvtap0 type l2 Обрати внимание на символическое устройство! Оно соответствует индексу интерфейса, как показывает "ip link show". Подними интерфейс с IP (да, IP надо настроить на самом хосте Proxmox, как минимум для ipvtap — иначе хост не понимает, куда маршрутизировать пакеты): ifconfig ipvtap0 netmask <маска> up
11.12.2021 17:48:00, ctr.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Tue, 09 Mar 2021 13:15:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Привет! В режиме мостового подключения (bridged mode) можно общаться со всеми виртуальными машинами (VM), LXC и хостом. Для хоста единственное отличие в том, что нужно добавить адаптер Macvtap. Можно добавить его с другим IP, в другой VLAN или полностью заменить Linux bridge на Macvtap. (То есть, в стандартной установке Linux bridge содержит IP Proxmox, а в нашем случае будет Macvtap.)

Есть еще много моментов, которые я не понимаю, например, почему сетевой интерфейс хоста должен быть в промискуитетном режиме и так далее... Но в целом Macvtap кажется технология будущего. Честно говоря, Macvtap для меня выглядит практически так же, как или сопоставим со SR-IOV. SR-IOV делит сетевую карту на аппаратном уровне, Macvtap делает что-то похожее на программном уровне.

Основная проблема в том, что мы даже не можем протестировать это на Proxmox, потому что конфигурационные файлы не дают такой возможности. Может кто-то знает способ или пробовал использовать?
09.03.2021 13:15:00, Ramalama.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Thu, 04 Mar 2021 21:35:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Похоже, я снова здесь, привет. Я знаком с hyperv и vmware, но последнее время экспериментирую с Proxmox, и, честно говоря, это просто великолепно. Почему я так долго до этого не дошёл? В любом случае, кажется, я как-то споткнулся здесь, придя из Macvtap LANd. @dietmar «В чём преимущество?» Вот что говорит IBM: «Драйвер MacVTap обеспечивает исключительную пропускную способность и количество операций в секунду (на 10-50% лучше, чем два программных моста). Кроме того, производительность MacVTap быстрее масштабируется с ростом нагрузки по сравнению с программным мостом. Это значит, что MacVTap более экономно расходует ресурсы CPU, выполняя одинаковую работу, но с меньшими затратами. Другими словами, MacVTap может выполнить больше работы на тех же CPU ресурсах. Однако, несмотря на лучшую производительность, у MacVTap есть несколько ограничений, которые могут ограничить области его применения. Первое — MacVTap не позволяет легко организовать сетевое взаимодействие между хостом KVM и гостями KVM, использующими MacVTap.»

Итак, macvtap — это драйвер ядра, который работает как tap, в отличие от программного маршрутизатора-моста, который использовался раньше (и активно используется до сих пор). Поверьте, документации по Macvtap в интернете довольно мало, но, по моим очень скромным тестам, он в целом работает как заявлено. Тем не менее, я считаю, что KVM уже довольно органично интегрируется с Macvtap. Например, вот конфигурация /etc/network/interfaces для KVM+Virt-Manager:

(к слову, я ещё не копался в причинах, но такой тип сетевой настройки плохо сочетается с некоторыми нестандартными systemd-конфигами, которые использует hypervisor Proxmox. ¯\_(ツ)_/¯ systemd жалуется, что не может перезапустить сеть, но она всё равно перезапускается и работает нормально... Я без понятия, почему. В общем, совсем неважно, просто решил упомянуть.)

Код:

auto lo
iface lo inet loopback

allow-hotplug enp1s0f0
auto enp1s0f0
iface enp1s0f0 inet static
address 10.8.0.30
netmask 255.255.240.0
gateway 10.8.0.1
dns-nameservers 10.80.0.5 10.10.10.10

auto enp1s0f0.4
iface enp1s0f0.4 inet manual
gateway 10.80.0.1
vlan-raw-device enp1s0f0

auto enp1s0f0.10
iface enp1s0f0.10 inet manual
gateway 10.10.10.1
vlan-raw-device enp1s0f0

auto enp1s0f0.24
iface enp1s0f0.24 inet manual
gateway 10.24.0.1
vlan-raw-device enp1s0f0

auto enp1s0f0.25
iface enp1s0f0.25 inet manual
gateway 10.25.0.1
vlan-raw-device enp1s0f0

Здесь я просто объявляю vlan-интерфейсы в сетевом конфиге, а если зайти в virt-manager и добавить новую виртуалку, то там можно выбрать эти vlan-интерфейсы как macvtap-мост, vepa, private или passthrough устройство.

И когда ВМ стартует, то вот как это выглядит в команде ip на хосте для любой ВМ с vlan-интерфейсом:

Код:

~# ip a
...
13: enp1s0f0.4@enp1s0f0: mtu 1500...
14: enp1s0f0.10@enp1s0f0: mtu 1500...
15: enp1s0f0.24@enp1s0f0: mtu 1500...
16: enp1s0f0.25@enp1s0f0: mtu 1500...
18: macvtap5@enp1s0f0: mtu 1500...
26: macvtap1@enp1s0f0: mtu 1500...
27: macvtap2@enp1s0f0.24: mtu 1500...
28: macvtap3@enp1s0f0.25: mtu 1500...

Я думаю, что virt-manager просто вызывает `ip link add` для этих macvtap-интерфейсов, а после создания они просто управляются ядром, пока их вручную не удалят… Но могу ошибаться.

Что стоит учесть про Macvtap:

Как уже упоминалось, нельзя пинговать IP хоста из гостевых систем в той же подсети. Вот тут и появляется NAT hairpinning. Но если гость на отдельном VLAN или другой подсети с собственным именем, то они проходят через NAT, что выполняет ту же функцию, что и hairpinning в документации. Это позволяет организовать связь между гостями и хостом по IP. Тем не менее, хотя я не могу пинговать хост с гостя и наоборот, virt-manager всё равно может управлять этими машинами через vnc/spice, так что какая-то связь есть. Может, управление идёт через vlan-интерфейс в macvtap, или этот tap игнорируется с точки зрения управления? Не знаю. Думаю, здесь нет однозначного ответа, но было бы здорово иметь возможность воспользоваться тем, что уже встроено в ядро десятки лет.

Мой случай — реанимировать старое железо, запуская proxmox на старых процессорах. Когда CPU загружен, это отражается и на сети. Думаю, macvtap мог бы помочь снизить нагрузку. А может и нет, я не гений.

Вот мои две копейки, а вы продолжайте в том же духе, я, пожалуй, начну мигрировать всё на proxmox.

Джек

P.S. На мой взгляд, основные проблемы с документацией по Macvtap возникли примерно в тот же период, когда в ядро внедряли cgroup networking. Macvtap никогда не рассматривали как простое решение, и с тех пор документация не обновлялась. Похоже, что Docker взял Macvtap на вооружение, и все начали думать, что это только для контейнеров ¯\_(ツ)_/¯
04.03.2021 21:35:00, oneill.

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP

Thu, 02 Jul 2020 13:21:00 +0300

MACVTAP как будущее замена классическим интерфейсам NIC+BRIDGE+TAP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Здравствуйте. Рассматриваете ли вы в будущем замену классического интерфейса Bridge+TAP (к сети ВМ) на MACVTAP? MACVTAP — относительно новая замена TAP-интерфейсу, при этом он использует /dev/tapXY, как и старый классический TAP, поэтому с QEMU он работает без проблем. Поскольку MACVTAP можно подключить напрямую к физической сетевой карте (так же, как и бридж), это позволяет отказаться от схемы LAN(NIC)+BRIDGE+TAP и использовать только LAN(NIC)+MACVTAP. Это более простое и, вероятно, более быстрое решение (без дополнительного слоя бриджа). Дополнительная информация: Source-1 Source-2 Source-3 (пример: QEMU+MACVTAP). Также есть MACVLAN как замена для подключения Network Namespaces (контейнеры Linux), аналогично VETH для Linux-контейнеров. С уважением, Hrvoje.
02.07.2020 13:21:00, mipsH.