Я только что нашел много разных способов создания сетей KVM. Но я застрял о том, как правильно это сделать. Я обнаружил, что openstack использует macvtap для создания нейтронных сетей. И это выглядит хорошо.
Но какая разница и зачем использовать каждый способ.
Способ 1 [СТАРЫЙ? TUN / TAP]
http://www.shakthimaan.com/installs/debian-tun-tap-setup.html
/--------\ /----\ /----\ /----\ /--------\
|Internet|---|eth0|---|br0 |---|tap0|---|Guest NIC
\--------/ \----/ \----/ \----/ \--------/
Устаревший, верно?
Способ 2 [Bridge + Vnet] <- это то, что делает virt-manager
http://www.linux-kvm.com/content/using-bridged-networking-virt-manager
В основном вы создаете мостовой интерфейс с вашим физическим интерфейсом внутри и
auto br0
#iface br0 inet dhcp
iface br0 inet static
address 172.16.0.100
network 172.16.0.0
netmask 255.255.0.0
broadcast 172.16.255.255
gateway 172.16.0.1
bridge_ports eth2
bridge_stp off
bridge_fd 0
bridge_maxwait 0
И когда вы запускаете виртуальную машину из virt-manager, интерфейс vnet создается и добавляется к мосту. По крайней мере, до тех пор, пока я не знаю. Интерфейс TUN / TAP не требуется.
Долгое время это работало довольно хорошо, но теперь с дерзостью я обнаружил проблемы.
https://bugs.launchpad.net/ubuntu/+source/core-network/+bug/1255516
Почему вы можете добавить новый интерфейс vnet на мост без интерфейса TAP?
Способ 3 [MACVTAP]
Последний интерфейс Macvtap.
http://virt.kernelnewbies.org/MacVTap
Он копирует программный интерфейс TUN / TAP, но делает это лучше. Не знаю, каким образом, но, кажется, лучше.
В чем преимущество macvtap перед вторым способом?
Что лучше?
Любая помощь в этом?
источник
Я бы сказал, что это зависит от вашего варианта использования.
Автоматизированные добавления / удаления виртуальных хостов?
Попробуйте Macvtap. Он также должен быть более производительным, чем macvlan (что примерно соответствует добавлению другого MAC к физическому устройству, информация о котором поступает туда, обрабатывается сетевым стеком) или дополнительным мостом, поскольку macvtap каким-то образом обходит сетевой стек и напрямую экспортирует символьное устройство. Но не приставай ко мне. Помимо того, что оба (macvlan / macvtap) используют одни и те же доступные режимы (VEPA / шпилька, мостовой, приватный), шпилька работает только в том случае, если ваш коммутатор поддерживает режим отражательного реле. (Пакеты, поступающие на физический коммутатор через порт x, должны иметь возможность снова покинуть коммутатор через тот же порт x.)
Поскольку eth0 (или тот, который вы используете) переводится в смешанный режим при использовании моста, говорят, что режимы macvXXX имеют более высокую пропускную способность.
Режимы также определяют «количество» изоляции (могут ли vhosts видеть трафик друг друга? Как насчет hv?). Как это работает под капотом я пока не знаю.
veth (виртуальные пары Ethernet) несколько похожи для изоляции: вы определяете два виртуальных интерфейса: один подключается к мосту, другой - к вашей виртуальной машине. Там изоляция осуществляется путем помещения vm-интерфейса в собственное пространство имен, чтобы устройства были несколько изолированы. Весь трафик собирается на мосту, но один vhost не может видеть vNIC другого.
Если вы работаете с мостом, у вас есть дополнительные настройки, и когда мост не работает, все ваши подключения. При восстановлении моста вам, возможно, придется снова подключить все виртуальные интерфейсы к мосту (или просто перезагрузить полную версию hv ...).
Итог: если вы не часто меняете свою топологию, просто переходите к мостовому соединению, поскольку вы найдете в нем наибольшую информацию, что лучше, чем чтение кода ядра. Черт возьми, даже самому пакету iproute2-doc не хватает большей части информации, которую действительно имеет iproute2, даже когда вы запускаете новейшие версии. Попробуйте узнать об этом
man ip-tcp_metricsиз доступных manpages или ip-crefs.ps ...источник
Эти методы делают принципиально разные вещи. Чтобы понять почему, вам нужно понять многоуровневую модель сетевого взаимодействия. Для наших целей здесь важны слои 1, 2 и 3:
MACVLAN / MACVTAP
MACVLAN создает виртуальный уровень 2 или устройство канального уровня со своим собственным MAC-адресом, который совместно использует уровень 1 или физический уровень с существующим устройством. Наиболее очевидно понятный случай, когда у вас есть устройство Ethernet, подключенное к сети, и вы создаете устройство MACVLAN на основе этого устройства Ethernet; Теперь у вас есть два Ethernet-устройства с разными MAC-адресами, но оба они передают свои кадры по одному и тому же кабелю. Я буду говорить о MACVTAP немного дальше.
Интерфейсы MACVLAN могут взаимодействовать несколькими различными способами с существующим интерфейсом Ethernet, в частности, когда на одном из интерфейсов появляется кадр, который адресован другому:
Обратите внимание, что интерфейсы MACVLAN имеют важное ограничение: они не способны к изучению адресов. Таким образом, вы не можете соединить интерфейс MACVLAN со вторым физическим устройством и ожидать, что сможете подключиться к этому второму физическому устройству через первое. Это работает с исходным интерфейсом Ethernet, но не с подключенным к нему интерфейсом MACVLAN.
TUN / TAP
Интерфейс TAP также является новым виртуальным устройством уровня 2, но к нему не подключен уровень 1. Вместо этого программа может получить дескриптор файла, представляющий физический уровень. Затем он может записать необработанные данные кадра Ethernet в этот файловый дескриптор, и ядро будет обрабатывать его как любой другой пакет Ethernet, полученный на реальном физическом интерфейсе.
Главное в интерфейсах TAP то, что физический уровень находится в режиме пользователя; любое программное обеспечение с соответствующими разрешениями может генерировать кадры Ethernet любым удобным для них способом и превращать их во что-то, что ядро рассматривает так же, как реальный физический интерфейс. Это делает их очень полезными для таких вещей, как VPN и туннелирование; Вы можете написать любое программное обеспечение для туннелирования, которое вам нравится, в пространстве пользователя, и вам не нужно вмешиваться в пространство ядра, чтобы поместить кадры в сетевой стек, вы просто создаете устройство TAP и записываете кадры в его файловый дескриптор.
Устройства TUN аналогичны устройствам TAP, за исключением того, что они работают на уровне 3 вместо уровня 2, и программное обеспечение пользовательского режима должно записывать необработанные IP-пакеты в файловый дескриптор вместо необработанных кадров Ethernet.
Возвращаясь к устройствам MACVTAP , это своего рода смешение между интерфейсами MACVLAN и TAP. Как и интерфейсы TAP, программа пользовательского режима может получить дескриптор файла и записать в него необработанные кадры Ethernet. Подобно интерфейсу MACVLAN, эти кадры затем отправляются через физический уровень реального устройства Ethernet. Это позволяет вам легко адаптировать программное обеспечение, написанное для использования устройств TAP, вместо устройства MACVLAN.
VNET
Это концептуально аналогично сетям TUN / TAP, но имеет более развитую плоскость управления (поэтому программное обеспечение пользовательского режима, использующее его, может более гибко настраивать интерфейс) и более оптимизированную плоскость данных (так что вы можете перемещать данные через виртуальное сетевое устройство более подробно). эффективно).
Все они делают подобные вещи, но имеют немного разные возможности. Все они могут быть использованы для подключения виртуальной машины к сети Ethernet:
источник