Глава 3. Построение сетей KVM при помощи libvirt

В libvirt мы можем определять различные типы сетевых сред для наших гостевых KVM при помощи уже известного нам синтаксиса определений XML и инструментов пространства пользователя virsh и virt-install. В этой главе мы намерены развернуть три типа сетевых сред, изучить соответствующий сетевой формат XML и рассмотреть примеры того как определять виртуальные интерфейсы для своих экземпляров KVM и как ими манипулировать.

Чтобы иметь возможность подключать виртуальные машины к ОС своего хоста или друг к другу, мы собираемся воспользоваться имеющимся мостом Linux и демонами Open vSwitch (OVS), инструментами пространства пользователя и модулями ядра. Обе технологии построения программного моста великолепны при создании Software-defined Networking (SDN, программно определяемой сетевой среды) различной сложности неким согласованным и простым в обращении образом. И мост Linux, и OVS, оба действуют как мост/ коммутатор, к которым могут подключаться имеющиеся у наших гостевых KVM виртуальные интерфейсы.

Имея это в виду, давайте начнём узнавать подробности программных мостов в Linux.

Мост Linux является неким программно определяемым устройством 2 уровня, который предоставляет необходимую функциональность какого- то физического устройства моста. Он способен переправлять кадры между гостевыми KVM, ОС своего хоста и виртуальными машинами, запущенными на прочих серверах или в иных сетевых средах. Мост Linux состоит из двух компонентов - инструмента администрирования пространства пользователя, который мы намерены применять в данном рецепте и какого- то модуля ядра, который и выполняет всю работу по соединению воедино множества сегментов Ethernet. Каждый создаваемый нами программный мост может иметь некое число подключённых к нему портов, где и происходит переадресация сетевого обмена в обоих направлениях. При создании экземпляров KVM мы можем подключать их виртуальные интерфейсы, которые ассоциированы с таким мостом, что аналогично вставке какого- то сетевого кабеля от некой NIC сервера в устройство моста/ коммутатора. Выступая в роли устройства 2 уровня, имеющийся мост Linux работает с MAC адресами и выполняет сопровождение некоторой структуры ядра по отслеживанию портов и ассоциированных MAC адресов в виде некоей таблицы Content Addressable Memory (CAM, ассоциативной памяти).

В данном рецепте мы намерены создать некий новый мост Linux и воспользоваться утилитой brctl для манипуляций с ним.

В данном рецепте нам потребуется следующее:

Чтобы создавать, перечислять и манипулировать новым мостом, выполните следующие шаги:

После того как мы впервые установили свой демон libvirt несколько моментов произошло в автоматическом режиме:

Давайте изучим установленные по умолчанию настройки моста libvirt:

root@kvm:~# cat /etc/libvirt/qemu/networks/default.xml
<network>
 <name>default</name>
 <bridge name="virbr0"/>
 <forward/>
 <ip address="192.168.122.1" netmask="255.255.255.0">
   <dhcp>
     <range start="192.168.122.2" end="192.168.122.254"/>
   </dhcp>
 </ip>
</network>
root@kvm:~#
		

Именно эту сетевую среду по умолчанию создал для нас libvirt, определив соответствующие название моста, адрес IP и тот диапазон IP, который используется запущенным сервером DHCP. Позднее в этой главе мы намерены обсудить более подробно сетевую среду libvirt; тем не менее мы показали её здесь чтобы помочь вам понять откуда появились все наши адреса IP и само название моста.

Мы можем обнаружить, что в ОС нашего хоста исполняется некий сервер DHCP и просмотреть его файл настройки с помощью такой команды:

root@kvm:~# pgrep -lfa dnsmasq
38983 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf
root@kvm:~# cat /var/lib/libvirt/dnsmasq/default.conf
##WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
##OVERWRITTEN AND LOST. Changes to this configuration should be made using:
## virsh net-edit default
## or other application using the libvirt API.
##
## dnsmasq conf file created by libvirt
strict-order
user=libvirt-dnsmasq
pid-file=/var/run/libvirt/network/default.pid
except-interface=lo
bind-dynamic
interface=virbr0
dhcp-range=192.168.122.2,192.168.122.254
dhcp-no-override
dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases
dhcp-lease-max=253
dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile
addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts
root@kvm:~#
		

В приведённом выше файле настроек отметим как устанавливается соответствие диапазона IP адресов для имеющейся службы DHCP и самого названия нашего виртуального моста, которые настроены в файле сетевой среды libvirt установок по умолчанию, который мы рассматривали выше.

Имея всё это в виду, давайте пройдём по всем выполненным нами ранее шагам.

На шаге 1 мы установили инструментарий пространства пользователя brctl, который мы будем применять для создания, настройки и инспектирования конфигурации своего моста Linux в своём ядре Linux.

На шаге 2 мы предоставили некий новый экземпляр KVM при помощи некого индивидуального сырого образа, содержащего необходимую гостевую ОС. Это шаг не требуется если вы выполняли все рецепты в наших предыдущих главах.

На шаге 3 мы вызвали свою утилиту bridge для перечисления всех доступных устройств моста. Из полученного вывода мы можем обнаружить что в настоящий момент у нас имеется один мост с названием virbr0, который был автоматически создан libvirt. Отметим, что в колонке интерфейса мы можем видеть интерфейс vnet0. Именно эта виртуальная NIC выставляется в ОС нащего хоста при запуске нами соответствующего экземпляра KVM. Это означает, что наша виртуальная машина подключена к мосту своего хоста.

На шаге 4 мы вначале отключаем имеющийся мост для его удаления, а затем снова применяем команду brctl для унчтожения этого моста и проверки того что он более не присутствует в ОС нашего хоста.

На шаге 5 мы повторно создаём необходимый мост и опять поднимаем его. Мы делаем это чтобы показать шаги, необходимые при создании какого- то нового моста.

На шаге 6 мы повторно назначаем тот же самый IP адрес своему мосту и просматриваем его.

На шагах 7 и 8 мы перечисляем все виртуальные интерфейсы в ОС своего хоста. Поскольку у нас имеется в настоящий момент только одна гостевая KVM, которая исполняется в нашем сервере, мы видим всего один виртуальный интерфейс, то есть vnet0. Затем мы переходим к добавлению/ подключению своего виртуального NIC к созданному мосту.

На шаге 9 мы включаем STP в своём мосте. STP является неким протоколом 2 уровня, который помогает нам предотвращать зацикливания в сетевой среде в случае когда у нас имеются избыточные сетевые пути. Это в особенности полезно при сетевых топологиях более крупного масштаба и более сложных, когда множество мостов соединяются друг с другом.

Наконец, на шаге 10 мы подключаемся к своей гостевой KVM при помощи консоли, перечисляем настройки её сетевых интерфейсов и убеждаемся что мы способны выполнить пинг к имеющемуся в ОС её хоста мосту. Для этого нам требуется поднять этот сетевой интерфейс внутри своего гостя с помощью ifconfig eth0 up, затем получить некий IP адрес при помощи команды dhclient eth0 от того сервера dnsmasq, который запущен на нашем хосте.

Существует ещё ряд полезных команд, которые могут применяться для имеющегося моста Linux.

Мы уже знаем что некий мост выполняет переадресацию кадров на основе тех MAC адресов, которые содержатся внутри него. Для изучения имеющейся таблицы MAC адресов, известных нашему мосту, исполните такую команду:

root@kvm:~# brctl showmacs virbr0
port no  mac addr               is local?      ageing timer
  1      52:54:00:55:9b:d6      no             268.02
  1      fe:54:00:55:9b:d6      yes            0.00
root@kvm:~#
		

В своём предыдущем выводе мы можем обнаружить что наш мост записал в свой порт два только два MAC адреса. Самая первая запись является нелокальным адресом и относится к тому сетевому интерфейсу, который находится внутри экземпляров KVM. Мы можем подтвердить это подключившись к своей гостевой KVM следующим образом:

root@kvm:~# virsh console kvm1
Connected to domain kvm1
Escape character is ^]

root@debian:~# ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
 link/ether 52:54:00:55:9b:d6 brd ff:ff:ff:ff:ff:ff
 inet6 fe80::5054:ff:fe55:9bd6/64 scope link
 valid_lft forever preferred_lft forever
root@debian:~#
		

Второй MAC адрес является адресом самого нашего моста и его MAC адрес имеющегося виртуального интерфейса, относящегося к имеющейся виртуальной машине, который выставляется ОС его хоста. Чтобы убедиться в этом исполните такую команду:

root@kvm:~# ifconfig | grep "fe:54:00:55:9b:d6"
virbr0 Link encap:Ethernet HWaddr fe:54:00:55:9b:d6
vnet0  Link encap:Ethernet HWaddr fe:54:00:55:9b:d6
root@kvm:~#
		

Когда наш мост видит некий кадр в одном из своих портов, он записывает значение времени, затем после того как на протяжении установленного промежутка времени он не наблюдает тот же самый MAC адрес снова, он удалит эту запись из своей таблицы CAM. Мы можем устанавливать в секундах этот временной предел до того как истечёт срок действия записи MAC адреса выполняя такую команду:

root@kvm:~# brctl setageing virbr0 600
root@kvm:~#
		

Команда brctl хорошо документирована; чтобы перечислить все доступные субкоманды, запустите её без параметров:

root@kvm:~# brctl
Usage: brctl [commands]
commands:
        addbr <bridge> add bridge
        delbr <bridge> delete bridge
        addif <bridge> <device> add interface to bridge
        delif <bridge> <device> delete interface from bridge
        hairpin <bridge> <port> {on|off} turn hairpin on/off
        setageing <bridge> <time> set ageing time
        setbridgeprio <bridge> <prio> set bridge priority
        setfd <bridge> <time> set bridge forward delay
        sethello <bridge> <time> set hello time
        setmaxage <bridge> <time> set max message age
        setpathcost <bridge> <port> <cost> set path cost
        setportprio <bridge> <port> <prio> set port priority
        show [ <bridge> ] show a list of bridges
        showmacs <bridge> show a list of mac addrs
        showstp <bridge> show bridge stp info
        stp <bridge> {on|off} turn stp on/off
root@kvm:~#
		

Большинство дистрибутивов Linux пакуют в свой состав обсуждаемую утилиту brctl и именно её мы и применяем в данном рецепте. Однако, чтобы воспользоваться самой последней версией или если пакет не доступен в вашем дистрибутиве, мы можем построить эту утилиту из исходного кда клонировав её проект с git, а затем выполнив настройку и скомпилировав её:

root@kvm:~# cd /usr/src/
root@kvm:/usr/src# apt-get update && apt-get install build-essential automake pkg-config git
root@kvm:/usr/src# git clone git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git
Cloning into 'bridge-utils'...
remote: Counting objects: 654, done.
remote: Total 654 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (654/654), 131.72 KiB | 198.00 KiB/s, done.
Resolving deltas: 100% (425/425), done.
Checking connectivity... done.
root@kvm:/usr/src# cd bridge-utils/
root@kvm:/usr/src/bridge-utils# autoconf
root@kvm:/usr/src/bridge-utils# ./configure && make && make install
root@kvm:/usr/src/bridge-utils# brctl --version
bridge-utils, 1.5
root@kvm:/usr/src/bridge-utils#
		

В своём предыдущем выводе мы можем наблюдать что вначале мы клонировали имеющийся для проекта bridge-utils репозиторий git, а потом скомпилировали полученный исходный код.

В хосте RedHat/CentOS этот процесс аналогичный:

[root@centos ~]# cd /usr/src/
[root@centos src]#
[root@centos src]# yum groupinstall "Development tools"
[root@centos src]# git clone git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git
Cloning into 'bridge-utils'...
remote: Counting objects: 654, done.
remote: Total 654 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (654/654), 131.72 KiB | 198.00 KiB/s, done.
Resolving deltas: 100% (425/425), done.
Checking connectivity... done.
[root@centos src]# cd bridge-utils
[root@centos bridge-utils]# autoconf
[root@centos bridge-utils]# ./configure && make && make install
[root@centos bridge-utils]# brctl --version
bridge-utils, 1.5
[root@centos bridge-utils]#
		

OVS является другим программно определяемым устройством моста/ коммутатора, который может применяться для создания различных виртуальных сетевых топологий и подключать к ним экземпляры KVM. OVS может использоваться вместо моста Linux и предоставляет расширенный набор свойств, включающих в свой состав политики маршрутизации, ACL (Access Control Lists, списки контролья доступа) политики QoS (Quality of Service, качества обслуживания), отслеживание сетевого обмена, управление потоком, выставление тегов VLAN, туннелирование GRE и многое другое.

В данном рецепте мы намереваемся установить, настроить и применить мост OVS для подключения некоего экземпляра KVM к ОС его хоста аналогично тому как мы это делали в своём предыдущем рецепте с помощью моста Linux.

Для работы с этим рецептом нам понадобятся гарантии следующего:

Для создания некого нового моста OVS и подключения имеющегося виртуального интерфейса некой гостевой KVM следуйте таким шагам:

Для упрощения нашей установки и во избежание конфликтов будет благоразумно вначале удалить имеющийся мост Linux, прежде чем создавать некий новый OVS. На 1 шаге мы удаляем имеющийся мост и опционально выгружаем его модуль ядра.

На шаге 2 мы устанавливаем пакет OVS, который также запускает основной необходимый демон OVS ovs-vswitchd, который отвечает за создание необходимых мостов/ коммутаторов и их изменение в ОС данного хоста.

На шаге 4 мы проверяем что модуль ядра OVS загружен, а на шаге 5 мы перечисляем все доступные коммутаторы OVS в данном хосте.

На шагах 6 и 7 мы создаём некий новый коммутатор OVS и добавляем имеющийся виртуальный интерфейс KVM в этот коммутатор.

Тот процесс сервера ovsdb, который также был запущен после установки основного пакета, и который мы видели на шаге 3, является неким механизмом базы данных, который применяет RPC (Remote Procedure Calls) JSON для взаимодействия со своим основным демоном OVS. Данный процесс сервера ovsdb запоминает информацию, например, относительно потоков, портов и QoS своего коммутатора, чтобы упоминуть хотя бы некоторую из возможной. Вы можете опрашивать эту базу данных исполняя такую команду:

root@kvm:~# ovsdb-client list-dbs
Open_vSwitch
root@kvm:~# ovsdb-client list-tables
Table
-------------------------
Port
Manager
Bridge
Interface
SSL
IPFIX
Open_vSwitch
Queue
NetFlow
Mirror
QoS
Controller
Flow_Table
sFlow
Flow_Sample_Collector_Set
root@kvm:~# ovsdb-client dump Open_vSwitch
...
Port table
_uuid bond_downdelay bond_fake_iface bond_mode bond_updelay external_ids fake_bridge interfaces lacp mac name other_config qos statistics status tag trunks vlan_mode
------------------------------------ -------------- --------------- --------- ------------ ------------ ----------- -------------------------------------- ---- --- -------- ------------ --- ---------- ------ --- ------ ---------
9b4b743d-66b2-4779-9dd8-404b3aa55e18 0 false [] 0 {} false [e7ed4e2b-a73c-46c7-adeb-a203be56587c] [] [] "virbr1" {} [] {} {} [] [] []
f2a033aa-9072-4be3-808e-6e0fce67ce7b 0 false [] 0 {} false [86a10eed-698f-4ccc-b3b7-dd20c13e3ee3] [] [] "vnet0" {} [] {} {} [] [] []
...
root@kvm:~#
		

Отметим, что в нашем предыдущем выводе теперь отображены эти новые коммутатор virbr1 и порт vnet0 когда мы опрашиваем имеющуюся базу данных OVS.

На шагах 8 и 9 мы назначаем IP адреса созданному коммутатору OVS и имеющейся гостевой KVM и проверяем что мы способны достигать полученный мост хоста изнутри своей виртуальной машины.

OVS является достаточно сложным программно определяемым коммутатором; в этом рецепте мы только чиркнули по его поверхности. В следующих нескольких рецептах мы можем применять как мост Linux, так и OVS с основными изменениями в настройках, на которые мы будем указывать по ходу действия.

Для удаления имеющегося виртуального интерфейса KVM из соответствующего коммутатора OVS выполните такую команду:

root@kvm:~# ovs-vsctl del-port virbr1 vnet0
root@kvm:~#
		

Чтобы полностью удалить имеющийся коммутатор OVS исполните такую команду:

root@kvm:~# ovs-vsctl del-br virbr1 && ovs-vsctl show
e5164e3e-7897-4717-b766-eae1918077b0
 ovs_version: "2.0.2"
root@kvm:~#
		

После своего запуска, libvirt создаёт некую сетевую среду по умолчанию в своём файле настроек /etc/libvirt/qemu/networks/default.xml. При построении какой- то новой KVM без определения каких бы то ни было новых сетевых параметров, она будет использовать такие настройки по умолчанию для взаимодействия с ОС своего хоста и прочими гостями, а также с сетевыми средами. Устанавливаемая по умолчанию сетевая среда libvirt применяет метод NAT (Network Address Translation, трансляции сетевых адресов). NAT предоставляет соответствие одного IP адреса другому, изменяя имеющийся IP адрес в самом заголовке данной IP дейтаграммы пакета. Это в особенности полезно когда наш хост предоставляет один IP адрес, позволяющий множеству гостей в одном и том же хосте применять этот адрес для установления исходящих соединений. Адреса таких виртуальных машин по существу транслируются чтобы проявляться как IP адрес этой машины хоста.

Сетевая среда переадресации по умолчанию определяет и настраивает некий мост Linux для подключения к нему имеющихся гостей. В данном рецепте мы собираемся создать некую новую сеть NAT и подключить к ней свою гостевую KVM.

В данном рецепте нам понадобится следующее:

Для настройки некоей новой сетевой среды NAT и подключения к ней какого- то экземпляра KVM выполните следующее:

Мы начали на шаге 1 с перечисления всех доступных сетевых сред в ОС своего хоста. Как мы можем видеть из получаемого вывода своей команды virsh, имеется запущенной только одна сетевая среда, установленная по умолчанию.

На шаге 2 мы изучаем имеющиеся настройки в этой установленной по умолчанию сетевой среды. Его определение XML использует следующие атрибуты:

На шаге 3 мы просматриваем файл настроек для установленной сети по умолчанию относительно перечисленного. Обратите внимание, что некоторые атрибуты пропущены. Libvirt автоматически вырабатывает определённые атрибуты и назначает значения по умолчанию так где это необходимо.

На шагах 4 и 5 мы проверяем что у нас имеется запущенный экземпляр, подключённый к установленному по умолчанию мосту Linux.

На шаге 6 мы создаём некое новое определение сетевой среды при помощи сети по умолчанию в качестве шаблона. Мы изменяем её название и определяем новый диапазон IP.

Имея готовым новый файл определения сетевой среды на шагах 7 и 8 мы определяем такую новую сеть, запускаем её и убеждаемся что она автоматически запускается при запуске самого демона libvirt в случае перезагрузки сервера.

После получения на шаге 9 дополнительной информации относительно вновь созданной сетевой среды мы продолжаем на шаге 10 изменять имеющееся определение XML соответствующей гостевой KVM. Чтобы сделать эту ВМ частью нашей новой сети всё что требуется, это обновить её элемент <source network>.

После перезапуска этой гостевой KVM на шаге 11 мы продолжаем на шаге 12 выводом списка всех доступных программно определяемых мостов в ОС своего хоста. Обратите внимание, что теперь у нас существует два моста, причём новый мост имеет подключёнными к нему виртуальные интерфейсы vnet0 с виртуальных машин.

Затем мы подключаемся к запущенной гостевой KVM и убеждаемся что её сетевой интерфейс eth0 получил некий IP адрес от своего сервера DHCP запущенного в этом хосте и что этот IP является частью того диапазона адресов, который мы настроили ранее. Мы также проверяем соединение при помощи команды ping.

Вернувшись в ОС своего хоста, на шагах 14 и 15 мы проверяем что службы DHCP запущены. Относительно вывода команды pgrep, обратите внимание что теперь у нас имеются два запущенных процесса dnsmasq: по одному для каждой из определённых сетей.

Переадресация NAT достигается установкой правил iptables, который мы можем видеть на шаге 18. Всякий раз когда мы определяем и запускаем некую новую сеть NAT, libvirt создаёт все необходимые правила в iptables. Из полученного на шаге 18 вывода мы можем видеть наличие двух наборов правил NAT, по одному для каждой запущенной сети NAT.

Полностью снарядив себя мостами мы можем подключать свои гостевые KVM напрямую к сетевой среде своего хоста без использования NAT. Однако такая установка требует некоего IP адреса, который является частью подсети самого хоста, причём для каждой виртуальной машины. Если у вас нет возможности выделять настолько много IP адресов, рассмотрите применение сети NAT, как это описано в выданном ранее рецепте Настройка переадресации NAT сетевой среды. При таком режиме построения сетевой среды ваши виртуальнве машины всё ещё используют для связи имеющийся мост ОС своего хоста; однако этот мост поглощает все физические интерфейсы, которые вы намерены применять для своих гостей.

В этом рецепте нам потребуется следующее:

Для определения некоторой новой сетевой среды с мостом и подключения к ней гостей выполните следующие шаги:

Для настройки сетевой среды с мостом на шагах 1 и 2 мы вначале выключаем некий физический интерфейс (в данном примере eth1), чтобы поглотить его (сделать его некоторой частью того нового моста, который мы намерены создать). Затем мы создаём некую сетевую конфигурацию, определяем новый необходимый мост и тот физический интерфейс, который мы намерены сделать частью этого моста. Это на самом деле устанавливает соответствие той подсети что мы настраиваем в данном физическом интерфейсе данному мосту. Если ваш сервер имеет только один сетевой интерфейс, вы всё ещё можете поглотить его. Однако вам потребуется некий дополнительный способ подключения к этому серверу, так как после того как вы отключите свой основной интерфейс, вы потеряете связь и устранение неисправностей может стать невозможным через какое- то подключение SSH.

После того как этот новый мост настроен, мы запускаем его на шаге 3.

На шаге 4 мы указываем своему ядру не применять правила iptable ни к какому обмену, появляющемуся у наших виртуальных гостей подключаемых к этому мосту Linux, поскольку мы не применяем никаких правил NAT.

После запуска своего нового интерфейса мы теперь на шаге 5 можем видеть свой мост и поглощённый им физический интерфейс, который мы подключили к нему.

На шаге 6 мы изменяем имеющееся определение XML своего экземпляра kvm1, в котором мы задаём необходимый тип сетевой среды который мы желаем применять; для данного рецепта это сеть с мостом (bridge). Если вы вспомните рецепт Настройка переадресации NAT сетевой среды, мы использовали тип сети (network) вместо сети с мостом и мы определяли некое название сети libvirt вместо самого названия моста.

Наконец, после перезапуска своего экземпляра KVM на шаге 7, наша гостевая ОС должна теперь иметь возможность достигать прочие экземпляры, которые являются частью той же самой подсети без использования NAT.

Обсуждаемый нами гипервизор KVM поддерживает прямое подключение устройств PCI из ОС своего хоста в его виртуальные машины. Мы можем применять эту функциональность для подключения сетевого интерфейса напрямую в имеющуюся гостевую ОС без необходимости применения NAT или программно определяемого моста.

В данном рецепте мы намерены подключить некую NIC (Network Interface Card), которая поддерживает SR-IOV (Single Root I/O Virtualization, виртуализацию ввода/ вывода с единым корнем) из своего хоста в соответствующего гостя KVM. SR-IOV представляет собой спецификацию, которая позволяет устройству PCIe (Peripheral Component Interconnect Express) выступать в виде множества физических устройств {Прим. пер.: виртуальных функций}, которые могут совместно применяться многими виртуальными машинами в одном и том же хосте, выполняя проброс на уровне самого супервизора, тем самым достигая естественной сетевой скорости. Поставщики облачных решений, такие как Amazon AWS выставляют эту функциональность для своих вычислительных экземпляров EC2 через вызовы API.

Для полного исполнения данного рецепта нам потребуется следующее:

Для настройки сетевой среды со сквозным PCIe проделайте следующие шаги:

Чтобы напрямую подключать NIC PCIe от ОС своего хоста в его гостевые ВМ нам вначале необходимо получить некую информацию об аппаратных средствах этого устройства, такую как домен, шина, слот и идентификаторы функций. На шаге 1 мы собираем информацию обо всех доступных устройствах в сервере своего хоста. Нас интересуют сетевой интерфейс, применяемый для eth1; более того мы выписываем из полученного вывода уникальную идентификацию PCI - в данном случае pci_0000_03_00_1.

Чтобы убедится что это на самом деле NIC, который мы бы хотели выставить своему гостю, мы перечисляем все устройства PCI на шаге 2. Из этого вывода мы можем обнаружить, что идентификатор его PCI тот же самый, 03:00.1.

Применяя PCI ID с шага 1 на шаге 3 мы продолжим собирать дополнительную информацию относительно NIC. Обратите внимание, что 0000_03_00_1 ID разбивается далее на идентификатор домена, идентификатор шины, идентификатор слота и идентификатор функции, как это показано в соответствующих атрибутах XML. Мы намерены воспользоваться ими на шаге 7; однако вначале нам необходимо преобразовать их в шестнадцатеричные числа, что мы и делаем на шаге 4.

На шагах 5 и 6 мы определяем некую новую сетевую среду libvirt для своих гостей и включаем автоматический сатр в случае перезапуска сервера своего хоста. Если вы выполняли прочие рецепты из этой главы, вы уже должны быть знакомы с большинством атрибутов в таком файле XML определений для той сети, которую мы только что создали. Режим hostdev определённый в атрибуте <forward> является именно тем, что инструктирует libvirt что наша новая сетевая среда намерена применять проброс PCI. Соответствующий параметр managed=yes, как это определено в нашем атрибуте <forward> сообщает libvirt вначале отключить это устройство PCI от хоста перед передачей его соответствующему гостю и повторно подключать его в этот хост после останова такого гостя. Наконец, субэлемент <pf> определяет тот физический интерфейс, который будет виртуализован и представлен соответствующему гостю.

На щаге 7 мы изменяем определение XML своего экземпляра KVM, определяя тот ID PCI, который мы получили на шаге 3 и определяем некий интерфейс, который будет применять новую сквозную сетевую среду PCIe, которую мы создали на шагах 5 и 6.

На шаге 8 мы перезапускаем свой экземпляр KVM и наконец проверяем что наше физическое устройство PCI NIC теперь является частью новой сквозной сетевой среды, определённой нами ранее. Обратите внимание на наличие множества устройств с типом PCI. Это происходит потому, что данное проброшенное устройство PCIe, которое мы будем применять, поддерживает SR-IOV. Все гостевые KVM, которые будут пользоваться этой сетевой средой теперь будут способны напрямую применять NIC своего хоста назначая одно из перечисленных виртуальных устройств PCie.

Libvirt предоставляет удобный способ управления сетевыми интерфейсами в имеющемся хосте через уже знакомый нам синтаксис определений XML. Мы можем применять команду virsh для определения, предоставления и удаления мостов Linux, а также получать дополнительную информацию относительно имеющихся сетевых интерфейсов, как мы это уже наблюдали в данной главе.

В данном рецепте мы намерены определить некий новый мост Linux, создать его и наконец удалить его с помощью virsh. Если вы вспомните наши более ранние рецепты, мы можем манипулировать имеющимся мостом Linux через такие утилиты как brctl. Для libvirt, однако, у нас имеется некий способ контроля этого программным путём через написание соответствующего файла определения и использование соответствующих компоновок API, которые мы рассмотрим в Главе 7, Применение Python для построения экземпляров KVM и управления ими.

Для данного рецепта нам потребуются:

Для создания нового интерфейса моста при помощи libvirt выполните такие команды:

На шаге 1 мы записываем необходимое определение XML для своего нового сетевого интерфейса. Мы определяем мост по значению типа, некого IP адреса для его интерфейса и необязательного какого- то MAC адреса.

На шагах 2 и 3 мы определяем этот новый мост и выводим его в списке. Определение такого интерфейса не делает автоматически его активным, поэтому на шаге 4 мы активируем его.

Как показано на шаге 5, активация этого моста создаёт его реальный интерфейс в этом хосте.

На шаге 6 мы убеждаемся что назначенные адреса IP и MAC действительно те, которые мы определили на шаге 1.

На шагах 7 и 8 мы получаем и название и MAC адрес при помощи утилиты virsh, а, наконец, на шаге 9 мы удаляем созданный интерфейс bridge.