Про сети и libvirt
Да оно и не беда, кабы здесь была еда. Окажись тут лебеда - так сошла б и лебеда...
Тезис: поддержка сети в libvirt'е сделана "на отъебись". Обоснование тезиса - прошу под кат.
Для начала я пробегусь по возможностям, которые нам предоставляет современный линукс по управлению множеством сетей и хостов. Речь не о банальной маршрутизации/фильтрации ip пакетов, а о той "магии", которую вы не найдёте больше нигде в таком количестве и многообразии.
vswitch
2 проекта - vde2 и open vswitch.
Киллер фичи первого - организация виртуального "ящика", эмулирующая свитч второго уровня с vlan'ами и stp (+ чуть-чуть третьего). Позволяет соединять между собой произвольное количество виртуалок БЕЗ создания интерфейсов на хосте в требуемом количестве. Соединения идут через unix-сокеты.
Более того - такие "коробочки" можно прозрачно соединять между собой, даже если они расположены на разных физических хостах. 1 tcp соединение, с опциональным шифрованием (dpipe + ssh).
Также, в эти "свитчи" можно втыкать стандартные tap/tun и ppp устройства, что позволяет воплотить большинство сетевых извращений, могущие прийти в голову продвинутому сисадмину.
Минусы - работает в userspace, нет штатной возможности зафиксировать конфигурацию.
Второй проект - напротив, рассчитан на максимальную производительность, поставляется со своим модулем ядра, сильно подпилен в сторону учёта трафика. Хорошие возможности по управлению множеством свитчей из одного места (см. ovsdb-server).
Также, есть штатные возможности по сохранению конфигурации настроенных свитчей.
Итого - первый более гибок и легковесен, но для долгоживущих, производительных и централизованных решений не приспособлен. Второй - наоборот.
tap/tun
Это 2 типа виртуальных интерфейсов, на которые опирается великое множество реализаций vpn'в и решений виртуализации. По сути, представляет собой ящик, скрывающий всю магию работы с сетевым стеком.
bridges
Применяются со времён царя Гороха, и просто объединяют несколько интерфейсов в один. Позже к ним добавили stp, возможность навешивать vlan'ы, но сути это не меняет.
В комбинации с предыдущим пунктом представляет собой наиболее распространённое решение по организации виртуальной сети.
Кучка tap'ов, по одному на виртуалку + один bridge с адресом, который выступает как шлюз между виртуалками и одновременно для общения такой сети с внешним миром.
macvtap/macvlan/veth
Дальнейшее развитие идеи "кучка tap'ов + bridge". Отличия описаны здесь.
Примерная схема работы этого счастья:
macvtap eth0
virt1 <--> [upper] <--> [lower] <--> [host]
virt2 <--> [ dev ] [ dev ]
3 режима работы:
- private -- пакеты между виртуалками не пересылаются вовсе, только на 'lower dev', а дальше - уже как оно или ближайший свитч решит
- vepa -- пакеты в между виртуалками пересылаются только в пределах одного и того же "upper dev", остальное - аналогично предыдущему
- bridge -- режим "гуляй, рванина", можно всё и всем.
Иными словами, может отделить виртуалки друг от друга посредством разных "upper dev", но тонко управлять этим доступом - фиг.
Отличное дополнение к вышесказанному здесь (картинки!) и в man'е lxc.conf
qemu
Теперь посмотрим, что у нас умеет в части сети сам qemu.
- user -- это ещё одна реализация vswitch с плюшками вроде встроенных dhcp, dns, tftp, проброса портов, и даже целых файловых систем (через самбу)
- tap -- понятно, пакеты пересылаются на это устройство, что с ними делать дальше - не проблемы qemu
- bridge -- вариация предыдущего пункта, создать tap и воткнуть его в уже существующий bridge.
- socket/tcp, socket/udp multicast -- понятно, позволяет соединить 2 машины без использования tap/bridge вообще, один unix-socket
- vde -- поддержка первого из вышеописанных виртуальных свитчей, второй работает через tap+bridge, так что он тоже поддерживается
libvirt
Возвращаясь к исходному тезису - а что из перечисленного в qemu умеет конфижить libvirt?
Короткий ответ - tap, bridge и user, всё. Причём в весьма покоцанном виде.
Например каждая из перечисленных опций qemu умеет сразу пихать трафик в указанный vlan. libvirt: - авотхуй!
Настраиваем bridge, хотим полностью изолированную сеть. libvirt: - авотхуй, правила в iptables я всё равно добавлю! И пару интерфейсов создам, чтоб не расслаблялся.
Хотим запрятать сеть подальше, чтоб хост про неё вообще не знал и в маршрутизации не учитывал. libvirt: - авотхуй, нету у меня поддержки в/у свитчей! И интерфейс я тебе всё равно создам, на всякий случай.
И всё многообразие {open,cloud,open}stack'ов, накрученное поверх libvirt'а - выше этой планки прыгнуть не способно.
А что у соседей?
А там не лучше, не обольщайтесь. ESXi, например вообще выпадает в ступор при упоминании nat'а на выходе из виртуальной сети. - Нащальника, какой нат? Щито такое? (концепция openvswitch, кстати, оттуда утянута)
Так что, здесь хотя бы есть возможность, хоть и нет удобства.