Похоже, я снова здесь, привет. Я знаком с 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: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...  
14: enp1s0f0.10@enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...  
15: enp1s0f0.24@enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...  
16: enp1s0f0.25@enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...  
18: macvtap5@enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...  
26: macvtap1@enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...  
27: macvtap2@enp1s0f0.24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...  
28: macvtap3@enp1s0f0.25: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 на вооружение, и все начали думать, что это только для контейнеров ¯\_(ツ)_/¯

Я поигрался с 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 <IP-виртуальной-машины> netmask <маска> up

Насколько я понимаю, единственное, что мешает полузависимой работе в 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/<tapname>/ifindex):

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

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

Мне пришлось потратить время на изучение вопроса, но оказалось, что и 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. Теперь я понимаю, что ты тоже упоминал это как известную проблему, которую это должно решить.

Окей, разобрался, скоро выложу исправления.

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