Proxmox: Openvswitch и сущность VLAN для него

Или VLAN в данном случае это аналог бриджа-шлюза, чтобы получить доступ к VM в подсети?

Сразу скажу - я с Proxmox не работал, сужу только по работе с openvswitch в контексте libvirt/opennebula.

Ну в общем-то да, если трафик из vlan планируется выпускать наружу, то логично, что кто-то должен всё это хозяйство маршрутизировать(и возможно nat-ить). Это может быть как что-то внешнее, либо один из гипервайзоров(хотя я считаю это не очень хорошей практикой, особенно если гипервайзоров несколько - чем меньше на них будет постороннего говна, тем лучше) или одна из виртуальных машин на этих гипервайзорах.

И вот в случае когда это один из гипервайзоров тебе и потребуется как-то вытащить из openvswitch интерфейс(в терминологии openvswitch он называется ЕНМИП internal interface) внутрь гипервайзора.

Плюс если у тебя в сервер идет несколько интерфейсов, объединенных в bonding(через тот же openvswitch) и ты не хочешь делать классическое разделение отдельными сетевухами на «управляющий интерфейс/служебная сеть кластера/трафик виртуальных машин», то как минимум управляющий интерфейс тебе придется в качестве internal делать(по умолчанию в openvswitch такой интерфейс есть и назван он аналогично имени свича) - иначе ты до сервера тупо не достучишься.

Разбираюсь с сабжем чисто для самообразования. с сабжем чисто для самообразования. Теперь мой вопрос: зачем VLAN’у может потребоваться назначать IP?

там же в доке написано.

VLANs Host Interfaces

In order for the host (e.g. proxmox host, not VMs themselves!) to utilize a vlan within the bridge, you must create OVSIntPorts. These split out a virtual interface in the specified vlan that you can assign an ip address to (or use DHCP). You need to set ovs_options tag=$VLAN to let OVS know what vlan the interface should be a part of. In the switch world, this is commonly referred to as an RVI (Routed Virtual Interface), or IRB (Integrated Routing and Bridging) interface.

Ну так у меня и вопрос, зачем может на практике потребоваться гипервизору Vlan по ip. Там есть реализация, но нет примеров использования.

Спасибо, теперь ситуация прояснилась.

Это нужно чтоб на хост попасть,как минимум. Без ip по L2 это будет проблематично…

Это и называется когнитивный диссонанс:

я привык, что классический VLAN это L2 без свойств L3 :-)

vlan это просто широковещательный домен (L2), если не нужен ip на vSwitch то можно и без ip. но если вирт машины не живут изолировано от мира, то ip дефолт гетвея где-то нужно же прописать? так вот этот ip всё равно будет прописан где-то. и да, это будет интерфейс именно в этом влане, разве что не на виртуальном коммутаторе а на физическом.

vlan это просто широковещательный домен (L2)

Я уже даже прочитал в Википедии, что могут быть ip-based VLAN’ы ;-)

Вот только толку от них мало.

В остальном понятно.

Это можно сформулировать короче: когда мы завернём сетевой интерфейс на котором висит гипервизор в OVS, нам нужно как-то на него попасть.

Отсюда все вытекающее.

Первый случай (два гипервизора) описал Pinkbyte.

Всем спасибо, вопрос решён.

Кстати, не подскажешь по OpenNebula каких-нибудь туториалов (можно текстом)?

А то, насколько я понял, Proxmox выезжает в основном за счет своей популярности у «домохозяек» :-)

Образно говоря.

Я настраивал по официальному howto - мне хватило. Перед этим почитал пару статей на хабре, типа этой. Заморачиваться отказоустойчивостью самой машины, где стоит сама рулилка opennebula я правда так и не стал - машина лежит на отдельном пуле в ceph, куда у самой opennebula нет доступа на запись, бэкапится отдельно + снапшоты rbd никто не отменял.

Вообще OpenNebula всё же немного не о том, пусть я и использую её как пускалку отдельных виртуальных машин, но сама идеология того что нельзя создать виртуальную машину без создания шаблона этой самой машины, намекает. А у меня такие машины - основные.

Сравнивать Proxmox и Opennebula, это как сравнивать LXC и Docker, к примеру. В докере тоже можно рожать отдельные контейнеры, не разделять stateful и stateless части, храня всё в одной ФС. Но забиванием гвоздей микроскопом это быть не перестанет.

Жалею ли я что выбрал Opennebula? Наверное всё же нет. Плацдарм для экспериментов на ней делать(когда надо родить пару десятков типовых виртуалок из шаблона) - одно удовольствие.

После опробованного мной oVirt-а так вообще - небо и земля(отдебажить проблемы работы oVirt я так и не осилил). А Proxmox 5 лет назад(когда я приценивался куда свалить с ручного руления тремя libvirt-нодами) в тандеме работы с ceph показался мне сыроватым по обзорам.

Т.к. в случае с классическим Linux Bridge (не рассматриваем VLAN Aware Bridge) мы имеем расклад Bridge per VLAN — сколько VLAN’ов, столько и бриджей.

4.2

См. vlan aware bridge

Теперь мой вопрос: зачем VLAN’у может потребоваться назначать IP?

Повесить туда management интерфейс.

Хотя я обычно на native vlan вешаю.

Но зачем нам доступ к самому VLAN’у (по ссылке на официальную доку)?

Глядя на пример: там есть ip на двух vlan’ах:

1. управление
2. ceph

А теперь прочти, что ты процитировал)

Спасибо, КО.

Но неизвестно насколько этот пример приближен к реальности, потому и создан этот топик.

Ответы получены, на теме отметка «решено».

И поскольку в доке у eth0 локальный IP не совсем очевидно, что это интерфейс управления.