В общем, поглядел-потрогал я этот ваш Open vSwitch. Теперь понял почему народ от него прётся / плюётся (нужное подчеркнуть).
Прежде чем озвучить какие-то рассуждения, нужно ознакомиться с некоторым background-ом / контекстом.
Факт №1. Есть такой программный продукт, называется VMWare. Помимо прочего в их решениях (за отдельные бабки) присутствует так называемый "Distributed Switch". Это некий виртуальный коммутатор, "типа размазанный" по всем гипервизорам. Вот это как раз и есть аналог Open vSwitch. Соответственно VMWare-ный "Standart Switch" — это как бы аналог "традиционных" Linux Bridge.
Факт №2. Несколько последних лет в Opensource идёт тенденция к тому, чтобы вообще убрать ядро операционной системы из цепочки передачи данных между ethernet-кабелем и приложением. Смысл в том, что мы включаем huge pages, копируем пачку данных с сетевого контроллера напрямую в страницу памяти и скармливаем её сразу приложению. Без промежуточных посредников, без генерации прерываний, без вызова системных функций, без копирования этой страницы памяти в другой диапазон адресов, без переключения контекста, просто вообще без ни хрена. Основная идея в том, что мы заводим в оперативке два буфера: пока один "наливается" данными из ethernet-адаптера, приложение обрабатывает второй. Потом они меняются местами. Такой подход позволяет какому-нибудь nginx-у уверенно прокачать через себя 38 Гбит/с и не закашляться. Более того, таким способом можно даже прямо на Java писать до фига HighLoad-приложения, даже библиотеки готовые под это дело есть.
Так вот, если мы начинаем говорить про QEMU/KVM-виртуализацию, то с точки зрения гипервизора виртуалка представляет собой userspace-приложение. И можно отдать ему трафик из провода "стандартными" средствами через прерывания и вот это всё. А можно как в предыдущем абзаце, мимо ядра гипервизора, при помощи стильных модных молодёжных технологий. И кому-то даже пофиг, что они требуют включения huge pages, колдовства с NUMA, не особо стабильные и местами даже откровенно глюкавые.
К чему я это всё? Ага, при условии наличия Intel-ёвых сетевых плат Open vSwitch умеет (при желании) вот в эту всю магию. Причём, сказанное справедливо не только для обмена трафиком между проводом и виртуалкой, но и между соседними виртуалками тоже. В последнем случае ускорение работы особенно заметно. Собственно именно как раз за это его и любят жарко и страстно. И второе его применение — инсталляции с большим количеством гипервизоров (в штуках), а-ля хостинги, кластеры, облака и т.п. Ибо централизованное управление и вроде как даже умение находить наиболее оптимальные маршруты на втором уровне.
Но если у вас не десятигигабитные потоки сетевого трафика и не сотни хостов, то связываться с Open vSwitch просто "чтоб было" вряд ли стоит. ИМХО, больше геморроя поимеете.
И немного про тёмную сторону некоторые аспекты практического применения в CentOS 8.1. Просто чтобы вы понимали весь масштаб бедствия.
На момент написания этой заметки (25.04.2020) официально стабильной LTS-версией Open vSwitch считалась 2.5.9. Но она работает только с ядрами 2.6.32—4.3. А в 8-й CentOS-и уже 4.18. Упс! То есть LTS-ку уже не воткнуть.
Дальше. Ручками нам собирать, как водится, лень. Смотрим что есть в официальных репозиториях. И видим... и видим... в репозитории "virt/ovirt-44" есть версия 2.11.1. Работает с ядрами до 4.18 включительно. Хм... как бы неплохо, но немного "на грани". Шаримся ещё немного по закромам и наблюдаем в репозитории "cloud/openstack-train" внезапно версию 2.12.0, ядра от 3.10 до 5.0. Круто! Вот это нам больше нравится. Вроде как.
Вот вы можете представить, чтобы в "репах" Debian-а в разных местах "валялись" бы одни и те же пакетики разных версий? Я — нет. Там если уж включили в релиз какую-то версию, то весь остальной зависимый софт будет собираться именно с ней. А тут чёрт-те что. Раздрай и шатание.
Ну ладно. Ставим версию 2.12.0 из "openstack-train" и... она не работает. Почему? Ах, ну да, SELinux же! Нельзя просто так взять и запустить на RedHat-клонах какую-нибудь софтину. Поэтому шаримся дальше. Видим два интересных пакетика, опять же, в разных репозиториях: "openstack-selinux-0.8.19" и "openvswitch-selinux-extra-policy-1.0-1
В первом пакете SELinux-политики для всего OpenStack вообще: там и HAProxy, и DNSMasq, и много чего ещё. Многовато будет. Во втором — только для Open vSwitch. Но он как бы "неродной", т.к. из другого репозитория, собран другой командой, для чуть более тухлой версии и под другие цели. И не факт, что там все политики безопасности прописаны "как надо". К тому же в пакетики они (политики) упакованы уже в скомпилированном виде, их так просто-быстро не посмотришь, надо рыться-искать исходники. Вот и что делать прикажете?
Но и это ещё не всё. Просто добавить модуль ядра мало, надо ещё как бе сконфигурировать сетевые интерфейсы и сам Open vSwitch. И тут мы "влетаем" в то, что NetworkManager / nmcli некоторыми функциями Open vSwtich типа Fake Bridges рулить тупо не умеет!
Тихо материмся и наблюдаем в репозитории "openstack-train" ещё один маленький неприметный пакетик по имени "network-scripts-openvswitch-2.12.0"
Дальше сами решайте, нужно ли оно вам. Чай, не маленькие.