История изменений
Исправление Pinkbyte, (текущая версия) :
Или VLAN в данном случае это аналог бриджа-шлюза, чтобы получить доступ к VM в подсети?
Сразу скажу - я с Proxmox не работал, сужу только по работе с openvswitch в контексте libvirt/opennebula.
Ну в общем-то да, если трафик из vlan планируется выпускать наружу, то логично, что кто-то должен всё это хозяйство маршрутизировать(и возможно nat-ить). Это может быть как что-то внешнее, либо один из гипервайзоров(хотя я считаю это не очень хорошей практикой, особенно если гипервайзоров несколько - чем меньше на них будет постороннего говна, тем лучше) или одна из виртуальных машин на этих гипервайзорах.
И вот в случае когда это один из гипервайзоров тебе и потребуется как-то вытащить из openvswitch интерфейс(в терминологии openvswitch он называется ЕНМИП internal interface) внутрь гипервайзора.
Плюс если у тебя в сервер идет несколько интерфейсов, объединенных в bonding(через тот же openvswitch) и ты не хочешь делать классическое разделение отдельными сетевухами на «управляющий интерфейс/служебная сеть кластера/трафик виртуальных машин», то как минимум управляющий интерфейс тебе придется в качестве internal делать(по умолчанию в openvswitch такой интерфейс есть и назван он аналогично имени свича) - иначе ты до сервера тупо не достучишься.
Исправление Pinkbyte, :
Или VLAN в данном случае это аналог бриджа-шлюза, чтобы получить доступ к VM в подсети?
Сразу скажу - я с Proxmox не работал, сужу только по работе с openvswitch в контексте libvirt/opennebula.
Ну в общем-то да, если трафик из vlan планируется выпускать наружу, то логично, что кто-то должен всё это хозяйство маршрутизировать(и возможно nat-ить). Это может быть как что-то внешнее, либо один из гипервайзоров(хотя я считаю это не очень хорошей практикой, особенно если гипервайзоров несколько - чем меньше на них будет постороннего говна, тем лучше) или одна из виртуальных машин на этих гипервайзорах.
И вот в случае когда это один из гипервайзоров тебе и потребуется как-то вытащить из openvswitch интерфейс(в терминологии openvswitch он называется ЕНМИП internal interface) внутрь гипервайзора.
Плюс если у тебя в сервер идет несколько интерфейсов, объединенных в bonding(через тот же openvswitch) и ты не хочешь делать классическое разделение «управляющий интерфейс/служебная сеть кластера/трафик виртуальных машин», то как минимум управляющий интерфейс тебе придется в качестве internal делать(по умолчанию в openvswitch такой интерфейс есть и назван он аналогично имени свича) - иначе ты до сервера тупо не достучишься.
Исправление Pinkbyte, :
Или VLAN в данном случае это аналог бриджа-шлюза, чтобы получить доступ к VM в подсети?
Сразу скажу - я с Proxmox не работал, сужу только по работе с openvswitch в контексте libvirt/opennebula.
Ну в общем-то да, если трафик из vlan планируется выпускать наружу, то логично, что кто-то должен всё это хозяйство маршрутизировать(и возможно nat-ить). Это может быть как что-то внешнее, либо один из гипервайзоров(хотя я считаю это не очень хорошей практикой) или одна из виртуальных машин на этих гипервайзорах.
И вот в случае когда это один из гипервайзоров тебе и потребуется как-то вытащить из openvswitch интерфейс(в терминологии openvswitch он называется ЕНМИП internal interface) внутрь гипервайзора.
Плюс если у тебя в сервер идет несколько интерфейсов, объединенных в bonding(через тот же openvswitch) и ты не хочешь делать классическое разделение «управляющий интерфейс/служебная сеть кластера/трафик виртуальных машин», то как минимум управляющий интерфейс тебе придется в качестве internal делать(по умолчанию в openvswitch такой интерфейс есть и назван он аналогично имени свича) - иначе ты до сервера тупо не достучишься.
Исправление Pinkbyte, :
Или VLAN в данном случае это аналог бриджа-шлюза, чтобы получить доступ к VM в подсети?
Сразу скажу - я с Proxmox не работал, сужу только по работе с openvswitch в контексте libvirt/opennebula.
Ну в общем-то да, если трафик из vlan планируется выпускать наружу, то логично, что кто-то должен всё это хозяйство маршрутизировать(и возможно nat-ить). Это может быть как что-то внешнее, один из гипервайзоров(хотя я считаю это не очень хорошей практикой) или одна из виртуальных машин на этих гипервайзорах.
И вот в случае когда это один из гипервайзоров тебе и потребуется как-то вытащить из openvswitch интерфейс(в терминологии openvswitch он называется ЕНМИП internal interface) внутрь гипервайзора.
Плюс если у тебя в сервер идет несколько интерфейсов, объединенных в bonding(через тот же openvswitch) и ты не хочешь делать классическое разделение «управляющий интерфейс/служебная сеть кластера/трафик виртуальных машин», то как минимум управляющий интерфейс тебе придется в качестве internal делать(по умолчанию в openvswitch такой интерфейс есть и назван он аналогично имени свича) - иначе ты до сервера тупо не достучишься.
Исходная версия Pinkbyte, :
Или VLAN в данном случае это аналог бриджа-шлюза, чтобы получить доступ к VM в подсети?
Сразу скажу - я с Proxmox не работал, сужу только по работе с openvswitch в контексте libvirt/opennebula.
Ну в общем-то да, если трафик из vlan планируется выпускать наружу, то логично, что кто-то должен всё это хозяйство маршрутизировать(и возможно nat-ить). Это может быть как что-то внешнее, один из гипервайзоров(хотя я считаю это не очень хорошей практикой) или одна из виртуальных машин на этих гипервайзорах.
И вот в случае когда это один из гипервайзоров тебе и потребуется как-то вытащить из openvswitch интерфейс(в терминологии openvswitch он называется ЕНМИП internal interface) внутрь гипервайзора.