Глава 17. Настройка устройства виртуальной машины

Red Hat Enterprise Linux 7 поддерживает три класса устройств для гостевых виртуальных машин:

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

  • Устрйства virtio (также именуемые паравиртуализацией) являются обеднёными виртуальными устройствами, разработанными для оптимальной работы в виртуальной машине. Устройства virtio аналогичны эмулируемым устройствам, однако по умолчанию не- Linux виртуальные машины не включают те драйверы, которые им необходимы. Программное обеспечение управления виртуализацией, такое как Диспетчер виртуальных машин (virt-manager) и гипервизор виртуализации Red Hat автоматически устанавливают эти драйверы для поддержки не- Linux гостевых операционных систем. Red Hat Enterprise Linux 7 поддерживает до 216 устройств virtio. Для получения дополнительных сведений обратитесь к Главе 5, Драйверы паравиртуализации KVM (virtio).

  • Назначаемые устройства являются физическими устройствами, которые выставляются в имеющиеся виртуальные машины. Данный метод такде известен как проброс (passthrough). Назначение устройства делает возможнымдля виртуальной машины исключительный доступ к устройствам PCI для некоторого диапазона задач, а также позволяет появляться устройствам PCI и вести себя так, как если бы они физически были подключены к имеющейся гостевой операционной системе. Red Hat Enterprise Linux 7 поддерживает до 32 назначаемых устройств для виртуальной машины.

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

Red Hat Enterprise Linux 7 поддерживает подключение устройств PCI в горячем режиме, выставляемые как функции отдельного слота в имеющиеся виртуальные машины. Устнойства хоста с отдельной функцией и индивидуальные функции устройств хоста со множеством функций могут быть настроены с их поддержкой. Настройка выставления устройств в качетсве слотов PCI со множеством функций в имеющиеся виртуальные машины рекомендуется только для приложений без поддержки с подключением в горячем редиме.

Для получения дополнительной информации об особых устройствах и связанных с ними ограничениях отсылаем вас к разделу 24.18 Устройства.

[Замечание]Замечание

Для полной изоляции некоторого гостя с назначенными устройствами из своего хоста требуется платформа с поддержкой переназначения прерывания. Без наличия такой поддержки данный хост может быть подвержен уязвимостям со стороны атак внедрения в прерывания от вредоносных гостей. В тех системах, в которых гости являются доверенными, выполняющий поддержку администратор может допускать назначение устройств PCI с применением опции allow_unsafe_interrupts для модуля vfio_iommu_type1. Это может выполняться на постоянной основе путём добавления некоторого файла .conf (local.conf) для /etc/modprobe.d, содержащего следующее:


options vfio_iommu_type1 allow_unsafe_interrupts=1
 	   

либо динамически с применением соответствующей записи sysfs чтобы сделать что- то похожее на:


# echo 1 > /sys/module/vfio_iommu_type1/parameters/allow_unsafe_interrupts
		

Устройства PCI

Назначение устройства PCI возможно только на аппаратных платформах, которые поддерживают либо Intel VT-d, либо AMD IOMMU. Эти спкцификации Intel VT-d bkb AMD IOMMU должны быть включены в самом BIOS хоста для того, чтобы работало назначение устройтва PCI.

 

Процедура 17.1. Подготовка системы Intel для назначения устройства PCI

  1. Разрешение спецификации Intel VT-d

    Спецификация Intel VT-d предоставляет аппаратную поддержку для прямого назначения некоторого физического устройства в какую- то виртуальную машину. Эти спецификации необходимы для применения назначения устройств PCI в Red Hat Enterprise Linux.

    Спецификация Intel VT-d должна быть включена в имеющемся BIOS. Некоторые производители систем хапрещают по умолчанию эти спецификации. Применяемая терминология для таких спецификаций может иметь различные названия у разных производителей, проконсультируйтесь с документацией своего производителя относительно применяемых названий.

  2. Активировать Intel VT-d в самом ядре

    Активируйте Intel VT-d в своём ядре добавив параметры intel_iommu=on и iommu=pt в самый конец строки GRUB_CMDLINX_LINUX внутри имеющихся кавычек в своём файле /etc/sysconfig/grub.

    Приводимый ниже пример является модификацией grub с активированным Intel VT-d.

    
    GRUB_CMDLINE_LINUX="rd.lvm.lv=vg_VolGroup00/LogVol01 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_VolGroup_1/root vconsole.keymap=us $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb quiet intel_iommu=on iommu=pt"
     	   
  3. Повторное создание файла настройки

    Выполните повторную генерацию файла /etc/grub2.cfg, исполнив:

    
    grub2-mkconfig -o /etc/grub2.cfg
    		

    Отметим, что если вы применяете хост на основе UEFI, вашим файлом назначения должен быть /etc/grub2-efi.cfg

  4. Готов к применению

    Для того чтобы изменения вступили в силу, перезагрузите свою систему. Теперь ваша система имеет возможность назначать устнойства PCI.

 

Процедура 17.2. Подготовка системы AMD для назначения устройства PCI

  1. Включение спецификации AMD IOMMU

    Для назначения устройства PCI в Red Hat Enterprise Linux требуются спецификации AMD IOMMU. Эти спецификации должны быть разрешены в BIOS. Некоторые производители оборудования отключают эти спецификации по усолчанию.

  2. Разрешить поддержку IOMMU ядром

    Добавьте в конец строки GRUB_CMDLINX_LINUX amd_iommu=pt внутри кавычек в /etc/sysconfig/grub с тем, чтобы спецификации AMD IOMMU разрешались при загрузке.

  3. Создайте повторно файл настройки

    Выполните повторную генерацию файла /etc/grub2.cfg, исполнив:

    
    grub2-mkconfig -o /etc/grub2.cfg
    		

    Отметим, что если вы применяете хост на основе UEFI, вашим файлом назначения должен быть /etc/grub2-efi.cfg

  4. Готов к применению

    Для того чтобы изменения вступили в силу, перезагрузите свою систему. Теперь ваша система имеет возможность назначать устнойства PCI.

[Замечание]Замечание

Для дополнительной информации об IOMMU обратитесь к Дополнению D. Работа с группами IOMMU.

  17.1.1. Назначение устройства PCI при помощи virsh

Ланный шаги обсуждают назначение устройство PCI виртуальной машине в гипервизоре KVM

Данный пример применяет контроллер сетевого устройства PCI с имеющимся у него кодом идентификатора PCI, pci_0000_01_00_0, а также полную гостевую виртуальную машину с названием guest1-rhel7-64.

 

Процедура 17.3. Назначение устройства PCI гостевой виртуальной машине с помощью virt

  1. Идентификация самого устройства

    Вначале опредеите само устройство PCI, предназначающееся для назначения устройства в определённую виртуальную машину. Воспользуйтесь командой lspci для вывода перечня всех доступных устройств PCI. Вы можете улучшить получаемый вывод lspci с помощью grep.

    Данный пример использует контроллер Ethernet, выделенный в следующем выводе:

    
    # lspci | grep Ethernet
    00:19.0 Ethernet controller: Intel Corporation 82567LM-2 Gigabit Network Connection
    01:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    01:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    		

    Данный контроллер Ethernet отображается со своим кортким идентификатором 00:19.0. Нам требуется определить полный идентификатор, применяемый virsh чтобы назанчить это устройство PCI в виртуальную машину.

    Для этого примените команду virsh nodedev-list чтобы отобразить перечень всех устройств определённого типа (pci), которые подключены к данной машине хоста. Затем пройдитесь по полученному выводу чтобы отыскать ту строку, которая соответстует необходимому короткому идентификатору того устройства, которое вы намереваетесь применять.

    Данный пример показывает ту строку, которая соответствует искомому контроллеру Ethernet с нужным нам коротким идентификатором 00:19.0. Отметим, что символы : и . замещаются подчёркиваниями в получаемом полном идентификаторе.

    
    # virsh nodedev-list --cap pci
    pci_0000_00_00_0
    pci_0000_00_01_0
    pci_0000_00_03_0
    pci_0000_00_07_0
    pci_0000_00_10_0
    pci_0000_00_10_1
    pci_0000_00_14_0
    pci_0000_00_14_1
    pci_0000_00_14_2
    pci_0000_00_14_3
    pci_0000_00_19_0
    pci_0000_00_1a_0
    pci_0000_00_1a_1
    pci_0000_00_1a_2
    pci_0000_00_1a_7
    pci_0000_00_1b_0
    pci_0000_00_1c_0
    pci_0000_00_1c_1
    pci_0000_00_1c_4
    pci_0000_00_1d_0
    pci_0000_00_1d_1
    pci_0000_00_1d_2
    pci_0000_00_1d_7
    pci_0000_00_1e_0
    pci_0000_00_1f_0
    pci_0000_00_1f_2
    pci_0000_00_1f_3
    pci_0000_01_00_0
    pci_0000_01_00_1
    pci_0000_02_00_0
    pci_0000_02_00_1
    pci_0000_06_00_0
    pci_0000_07_02_0
    pci_0000_07_03_0
    		

    Запишите требуемый номер устройства PCI, который соответствует тому устройству, что вы желаете применять; он понадобится в последующих шагах.

  2. Просмотр информации об устройстве

    Из вывода команды virsh nodedev-dumpxml доступна информация о домене, шине и функции:

     

    Рисунок 17.1

    
    # virsh nodedev-dumpxml pci_0000_00_19_0
    
    <device>
      <name>pci_0000_00_19_0</name>
      <parent>computer</parent>
      <driver>
        <name>e1000e</name>
      </driver>
      <capability type='pci'>
        <domain>0</domain>
        <bus>0</bus>
        <slot>25</slot>
        <function>0</function>
        <product id='0x1502'>82579LM Gigabit Network Connection</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
        <iommuGroup number='7'>
          <address domain='0x0000' bus='0x00' slot='0x19' function='0x0'/>
        </iommuGroup>
      </capability>
    </device>
    		
    Содержимое дампа

     
    [Замечание]Замечание

    Некая нруппа IOMMU определяется на основании имеющихся видимости и изоляции устройств с точки зрения самого IOMMU. Каждая группа IOMMU может содержать одно или более устройств. Когда представлено множество устройств, все конечные точки внутри такой группы IOMMU должны быть заявлены для всех устройств внутри данной группы чтобы назначать их гостю. Это можно осуществить либо посредством также назначением дополнительных конечых точек этому гостю, либо отсоединяя их от своего драйвера хоста с применением virsh nodedev-detach. Содержащиеся внутри отдельной группы устройства не могут быть расщеплены между хостом и гостем. Не являющиеся оконечными точками устройства, такие как порты корня PCIe, порты коммутатора и мосты нет необходимости отсоединять от их драйверов хоста и они не оказывают влияния на назначение конечных точек.

    Устройства внутри некоторой группы IOMMU могут быть определены с помощью раздела iommuGroup в получаемом выводе virsh nodedev-dumpxml. Каждый участник этой группы представлен в отдельном поле "адрес". Данную информацию можно также обнаружить в sysfs при помощи следующего:

    
    $ ls /sys/bus/pci/devices/0000:01:00.0/iommu_group/devices/
    		

    Некий образец вывода такой команды может представлять собой:

    
    0000:01:00.0   0000:01:00.1
    		

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

    
    $ virsh nodedev-detach pci_0000_01_00_1
    		
  3. Определение необходимых подробностей настройки

    Для получения тех значений, которые требуются вашему файлу настройки, воспользуйтесь получаемым из команды virsh nodedev-dumpxml pci_0000_00_19_0 выводом.

    Устройтсво нашего примера имеет следующие значения: bus = 0, slot = 25 и function = 0. Десятичные настройки применяют эти три значения:

    
    bus='0'
    slot='25'
    function='0'
     	   
  4. Добавление подробностей настройки

    Выполните virsh edit, определив необходимое название виртуальной машины и добавьте запись устройства в соответствующем разделе <source> чтобы назначить это устройство PCI в редактируемую гостевую виртуальную машину.

     

    Рисунок 17.2

    
    # virsh edit guest1-rhel7-64
    
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0' bus='0' slot='25' function='0'/>
      </source>
    </hostdev>
    		
    Добавление устройства PCI

    В качестве альтернативы выполните virsh attach-device, определив название нужной виртуальной машины и соответствующий файл XML гостя:

    
    virsh attach-device guest1-rhel7-64 file.xml
    		
  5. Запустите эту виртуальную машину

    
    # virsh start guest1-rhel7-64
    		

Данное устройство PCI теперь должно быть успешно назначено соответствующей виртуальной машине и доступно для её гостевой операционной системы.

  17.1.2. Назначение устройства PCI при помощи virt-manager

Устройства PCI могут добавляться в виртуальные машины с помощью графического инструментария virt-manager. Приводимая далее процедура добавляет контроллер гигабитного Ethernet в гостевую виртуальную машину.

 

Процедура 17.4. Назначение устройства PCI гостевой виртуальной машине с помощью virt-manager

  1. Откройте установки оборудования

    Откройте свою гостевую машину и кликните кнопку Add Hardware для добавления нового устройства в эту виртуальную машину.

     

    Рисунок 17-3


    Информационное окно оборудования виртуальной машины

  2. Выберите устройство PCI

    Выберите PCI Host Device из списка Hardware, расположенного слева.

    Выберите неиспользуемое устройство PCI. Отметим, что выбор устройств PCI, находящихся в настоящее время в использовании другим гостем вызывает ошибки. В данном примере используется запасной аудио контроллер. Кликните Finish для завершения установки.

     

    Рисунок 17-4


    Мастер добавления нового виртуального оборудования

  3. Добавить новое устройство

    Данная установка завершена и рассматриваемая гостевая виртуальная машина теперь имеет прямой доступ к выбранному устройству PCI.

     

    Рисунок 17-5


    Информационное окно оборудования виртуальной машины

[Замечание]Замечание

Если вы получили отказ в назначении устройства, могут иметься прочие оконечные точки в той же самой группе IOMMU, которые всё ещё подключены к данному хосту. Не существует возможности выборки информации о группе при помощи virt-manager, однако для анализа ограничений данной группы IOMMU и, если понадибится, последующих устройств, можно применить команды virsh.

Для получения дополнительной информации о группах IOMMU и том, как отсоединять устройства конечной точки с помощью virsh, воспользуйтесь Замечанием в разделе 17.1.1. Назначение устройства PCI при помощи virsh.

  Назначение устройства PCI при помощи virt-install

Имеется возможность назначать устройство PCI при установке некоторого гостя с применением команды virt-install. Для этого воспользуйтесь параметром --host-device.

 

Процедура 17.5. Назначение устройства PCI виртуальной машине с помощью virt-instal

  1. Определите устройство

    Идентифицируйте то устройство PCI, которое предполагается назначить выбранной гостевой виртуальной машине.

    
    # lspci | grep Ethernet
    00:19.0 Ethernet controller: Intel Corporation 82567LM-2 Gigabit Network Connection
    01:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    01:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
     	   

    Команда virsh nodedev-list перечислит все устройства, подключённые к применяемой системе и укахет некую строку для каждого устройства PCI. Для ограничения устройствами PCI введите следующую команду:

    
    # virsh nodedev-list --cap pci
    pci_0000_00_00_0
    pci_0000_00_01_0
    pci_0000_00_03_0
    pci_0000_00_07_0
    pci_0000_00_10_0
    pci_0000_00_10_1
    pci_0000_00_14_0
    pci_0000_00_14_1
    pci_0000_00_14_2
    pci_0000_00_14_3
    pci_0000_00_19_0
    pci_0000_00_1a_0
    pci_0000_00_1a_1
    pci_0000_00_1a_2
    pci_0000_00_1a_7
    pci_0000_00_1b_0
    pci_0000_00_1c_0
    pci_0000_00_1c_1
    pci_0000_00_1c_4
    pci_0000_00_1d_0
    pci_0000_00_1d_1
    pci_0000_00_1d_2
    pci_0000_00_1d_7
    pci_0000_00_1e_0
    pci_0000_00_1f_0
    pci_0000_00_1f_2
    pci_0000_00_1f_3
    pci_0000_01_00_0
    pci_0000_01_00_1
    pci_0000_02_00_0
    pci_0000_02_00_1
    pci_0000_06_00_0
    pci_0000_07_02_0
    pci_0000_07_03_0
     	   

    Запишите необходимый номер устройства PCI; этот номер понадобится на последующих этапах.

    Информация о получаемых значениях домена, шины и функции доступна в выводе команды virsh nodedev-nodedevdumpxml:

     

    Рисунок 17.6

    
    # virsh nodedev-dumpxml pci_0000_01_00_0
    
    <device>
      <name>pci_0000_01_00_0</name>
      <parent>pci_0000_00_01_0</parent>
      <driver>
        <name>igb</name>
      </driver>
      <capability type='pci'>
        <domain>0</domain>
        <bus>1</bus>
        <slot>0</slot>
        <function>0</function>
        <product id='0x10c9'>82576 Gigabit Network Connection</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
        <iommuGroup number='7'>
          <address domain='0x0000' bus='0x00' slot='0x19' function='0x0'/>
        </iommuGroup>
      </capability>
    </device>
     	   
    Содержимое файла устройства PCI

    [Замечание]Замечание

    Если имеется множество оконечные точки в той рассматриваемой группе IOMMU и не все они назначены соответствующим гостям, вам понадобится вручную отсоединить прочие конечные точки от их хоста выполнив следующую команду, прежде чем запускать данного гостя:

    
    $ virsh nodedev-detach $ virsh nodedev-detach pci_0000_00_19_1pci_0000_00_19_1
     	   

    Для получения дополнительной информации о группах IOMMU и том, как отсоединять устройства конечной точки с помощью virsh, воспользуйтесь Замечанием в разделе 17.1.1. Назначение устройства PCI при помощи virsh.

  2. Добавление требуемого устройства

    Воспользуйтесь поученным из команды virsh nodedev идентификатором в качестве значения для параметра --host-device.

    
    virt-install \
    --name=guest1-rhel7-64 \
    --disk path=/var/lib/libvirt/images/guest1-rhel7-64.img,size=8 \
    --vcpus=2 --ram=2048 \
    --location=http://example1.com/installation_tree/RHEL7.0-Server-x86_64/os \
    --nonetworks \
    --os-type=linux \
    --os-variant=rhel7
    --host-device=pci_0000_01_00_0
     	   
  3. Завершите установку

    Завершите установку данного гостя. Необходимое устройство PCI должно подключиться к этому гостю.

  Отключение назначенного устройства PCI

Когда некое устройство PCI было назначено гостевой машине, сам хост больше не может больше использовать это устройство. Если это устройство находится в режиме управляемого (настроенного с применением параметра managed='yes' в соотвествующем файле домена XML), оно подключается к своей гостевой машине и отключается от этой гостевой машины и затем подключается к основной машине хоста по мере необходимости. Если рассматриваемое устройство не находитя в режиме управляемого, вы можете отключить это устройство PCI от его гостевой машины и повторно подключить его с применением virsh или virt-manager.

 

Процедура 17.6. Отключение устройства PCI от гостя с помощью virsh

  1. Bold

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

    
    # virsh detach-device name_of_guest file.xml
    		
  2. Повторное подключение этого устройства к его хосту (опциональное)

    Если ваше устройство находится в управляемом режиме, пропустите этот шаг. Ваше устройство будет возвращено своему хосту автоматически.

    Если ваше устройство не применяет режим управляемго, примените следующую команду для повторного подключения этого устройства PCI к его машине хоста:

    
    # virsh nodedev-reattach device
    		

    Ваше устройство теперь доступно для его использования хостом.

 

Процедура 17.7. Отключение устройства PCI от гостя с помощью virt-manager

  1. Откройте экран подробностей виртуального оборудования

    в virt-manager кликните дважды по той виртуальной машине, которая содержит данное устройство. Выберите кнопку Show virtual hardware details для отображения перечня виртуального оборудования.

     

    Рисунок 17-7


    Кнопка подробностей виртуального оборудования

  2. Выберите и удалите требуемое устройство

    Выберите то устройство PCI, которое подлежит отсоединению от данного перечня виртуальных устройств в левой панели.

     

    Рисунок 17-8


    Выбор устройства PCI, подлежащего отключению

    Кликните по кнопке Remove для подтверждения. Данное устройство теперь доступно для применения хостом.

  Создание мостов PCI

Мосты PCI (Peripheral Component Interconnects, межсоединения периферийных компонентов) применяются для подключения таких устрйоств, как сетевые карты, можемы и звуковые карты. В точности также как и свои физические противоположности, виртуальные устройства могут также подключаться к мосту PCI. Раньше к любой гостевой виртуальной машине можно было подключать только 31 устройство PCI. Теперь, когда добавлено 31 устройство PCI, в 31 слот автоматически добавляется мост PCI помещая дополнительные устройства PCI в такой мост PCI. Каждый мост PCI имеет 31 дополнительных слотов для дополнительных 31 устройств, причём каждое из них в свою очередь может быть мостом. Тем самым, в гостевых выиртуальных машинах может быть доступно более 900 устройств. Отметим, что данное действие не может выполняться при работающей гостевой виртуальной машине. Вы должны добавлять свои устройства PCI в гостевой виртуальной машине, которая остановлена.

 

Поддержка подключения/ отключения в горячем режиме моста PCI

Подключения/ отключения моста PCI в горячем режиме поддерживается в следующих типах устройств:

  • virtio-net-pci

  • virtio-scsi-pci

  • e1000

  • rtl8139

  • virtio-serial-pci

  • virtio-balloon-pci

  Ограничения назначения устройств PCI

Назначение устройств PCI (подключение устройств PCI к виртуальным машинам) требует наличия в хост системах поддержки AMD IOMMU или Intel VT-d для возможности назначения устройств для аппаратуры PCIe.

Red Hat Enterprise Linux 7 имеет ограниченное пространство настроек PCI, доступное гостевым драйверам устройств. Такое ограничением может вызвать то, что те драйверы, которые зависят от возможностей устройства или свойств, представленных в таком расширенном пространстве настроек PCI, могут получить отказ в настройке.

Существует некий общий предел в 32 назначенных устройства на виртуальную машину Red Hat Enterprise Linux 7. Это транслируется в общее количество в 32 функции PCI, вне зависимости от общего числа представленных в такой виртуальной машине мостов PCI или того как эти функции комбинируются для создания слотов со множеством функцией.

Для полной изоляции гостя с назначенными устройствами из своего хостатребуется платформа с поддержкой переназначения прерываний. Без наличия такой поддержки хост может испытывать уязвимости со сторон атак инъекции в прерывание от вредоносных гостей. В некоторой среде, в которой гости являются доверенными, администратор может продолжить обслуживание назначение устройства PCI с применением опции allow_unsafe_interrupts в модуле vfio_iommu_type1. Это может быть либо выполнено на постоянной основе, либо через добавление файла .conf (например, local.conf) в /etc/modprobe.d, содержащем следующее:


options vfio_iommu_type1 allow_unsafe_interrupts=1
		

или динамически с применением записи sysfs чтобы сделать то же самое:


# echo 1 > /sys/module/vfio_iommu_type1/parameters/allow_unsafe_interrupts
		

Назначение устрйоств PCI устройствам SR-IOV

Сетевое устройство PCI (определяемое в домене XML своим элементом <source>) может быть непосредственно подключено к конкретному гостю с применением прямого назначения устройства (иногда именуемого как проброс - passthrough)ю из- за ограничений в стандарте архитектуре драйвера карты PCI ethernet отдельного порта, только устройства virtual function (VF, виртуальных функций) SR-IOV (Single Root I/O Virtualization, Виртуализации ввода/ вывода с единым корнем) могут назначаться таким образом; чтобы назначить гостю некую стандартную карту Ethernet PCI или PCIe с единственным портом, применяйте обычное определение устройства <hostdev>.

 

Рисунок 17.9


<devices>
  <interface type='hostdev'>
    <driver name='vfio'/>
    <source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </source>
    <mac address='52:54:00:6d:90:02'>
    <virtualport type='802.1Qbh'>
      <parameters profileid='finance'/>
    </virtualport>
  </interface>
</devices>
 	   
Образец XML для назначения устройства PCI

Разработанная PCI-SIG (PCI Special Interest Group), спецификация SR-IOV (Single Root I/O Virtualization, Виртуализации ввода/ вывода с единым корнем) является стандартом для некоторого типа назначения устрйоств PCI, которые могут совместно использовать некое отдельное устройство для множества виртуальных машин. SR-IOV улучшает производительность устройства для виртуальных машин.

 

Рисунок 17-10


Как работает SR-IOV

SR-IOV включает Функцию общего корня (например, некий единый порт Ethernet) чтобы проявляться как множественное, отдельное физическое устройство. Некое физическое устройство с возможностями SR-IOV может быть настроено с тем, чтобы проявиться в общем пространстве настройки PCI в виде множества функций. Каждое устройство имеет своё собственное полное пространство настроек с BAR (Base Address Registers, Регистрами базового адреса, {Прим. пер.: подробнее в нашем переводе Глава 4. Пространство адресов и маршрутизация транзакций руководства "Технология PCI Express 3.0" Майка Джексона и Рави Бадрака.})

SR-IOV применяет два вида функций PCI:

  • Физические функции (PF, Physical Functions) являются полными устройствами PCIe, которые содержат возможности SR-IOV. Физические функции поддерживают обнаружение, являются управляемыми и настраиваемыми как обычные устройства PCI. Физические функцие настраиваются и управляются определённой функциональностью SR-IOV через назначение Виртуальных функций.

  • Виртуальные функции (VF, Virtual Functions) являются простейшими функциями PCIe, которые только обрабатывают ввод/ вывод. Всякая виртуальная функция производится из некоей Физической функции. Общее число Виртуальных функций, которе может иметь устройство ограничени самими оборудованием устройства. Некий отдельный порт Ethernet, Физическое устройство, может устанавливать соответствие множеству Виртуальных функций, которые могут совместно применяться виртуальными машинами.

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

Каждая Виртуальная функция может назначаться только одному гостю за раз, так как Виртуальная функция нуждается в реальных ресурсах оборудования. Всякая виртуальная машинв может иметь множество Виртуальных функций. Виртуальная функция появляется в качестве сетевой карты точно так же как обычная сетевая карта появилась бы в операционной системе.

Драйверы SR-IOV реализуются в самом ядре. Такая реализация ядра содержится в имеющейся подсистеме PCI, однако так же должен иметься драйве поддержки как для устройств Физической функции (PF), так и для устройств Виртуальной функции (VF). Некое устройство с возможностью SR-IOV может выделять VF из PF. Такие VF появляются как устройства PCI, которые имеют основой само физическое устройство PCI такими ресурсами как очереди и наборы регистров.

  Преимущества SR-IOV

Устройства SR-IOV могут совместно применять отдельный физический порт для множества виртуальных машин.

Когда VF SR-IOV назначена виртуальной машине, она может бть назначена (прозрачно для этой виртуальной машины) на место всего сетевого обмена, покидающего VF в какую- то определённую VLAN. Сама виртуальная машина не может определять что её обмен помечен для какой- то VLAN и не может запрещать или прекращать такую пометку.

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

Эти свойства делают возможным увеличение плотности виртуальных машин в хостах в рамках некоторого центра данных.

SR-IOV лучше приспособлены к применению общей полосы пропускания устройств со множеством гостей.

  Применение SR-IOV

Данный раздел обсуждает применение проброса PCI для нзначения Виртуальной функции некоторой сетевой карты со множеством портов и возможностью SR-IOV в виртуальную машину в качестве сетевого устройства.

Виртуальные функции (VF) SR-IOV могут назначаться виртуальным машинамчерез добавление какой- то записи в <hostdev> при помощи команд virsh edit или virsh attach-device. Однако, это может быть проблематичным, так как в отличии от обычных сетевых устройств, сетевое устройство VF SR-IOV не имеют некоторого постоянного уникального MAC адреса и при всякой перезагрузке её хоста всякий раз назначается некий новый MAC адрес. Из- за этого даже если такой гость назначается той же самой VF после перезагрузки, когда его хост перезагружается, такой гость определяет свой сетевой адаптер как имеющий некий новый MAC адрес. В качестве результата такой гость полагает, что имеется некое новое оборудование при всяком новом подкдючении и это обычно требует повторной настройки сетевых установок этого гостя.

libvirt содержит определённое устройство интерфейса <interface type='hostdev'>. Применяя это устройство интерфейса, libvirt будет вначале выполнять всякую инициализацию индикации оборудования/ коммутатора, специфичную для сети (такую как установка MAC адреса, тег VLAN или параметры виртуального порта 802.1Qbh), а затем выполнить соотвествующее назначение этого устройства PCI данному гостю.

Применение интерфейса устройства <interface type='hostdev'> требует:

  • сетевой карты с возможностями SR-IOV

  • оборудования хоста, который поддерживает либо расширение Intel VT-d, либо расширения AMD IOMMU

  • подлежащего назначению определённого адреса PCI этой VF

[Предостережение]Предостережение

Назначение некоторого устройства SR-IOV виртуальной машине требует чтобы само оборудование хоста поддерживает спецификации Intel VT-d или AMD IOMMU.

Для подключения сетевого устройства SR-IOV какой- то системе Intel или AMD, придерживайтесь следующей процедуры:

 

Процедура 17.8. Подключение сетевого устройства SR-IOV в системе Intel или AMD

  1. Включите спецификации Intel VT-d или AMD IOMMU в самом BIOS и в ядре

    В системе Intel включите в BIOS Intel VT-d, если это ещё не сделано. Отсылаем вас к Процедуре 17.1. Подготовка системы Intel для назначения устройства PCI для помощи в операции включения Intel VT-d в своём BIOS и ядре.

    Если Intel VT-d уже работают, пропустите этот шаг.

    В системе AMD включите спецификации AMD IOMMU в вашем BIOS если они ещё не разрешены. Отсылаем вас к Процедуре 17.2. Подготовка системы AMD для назначения устройства PCI для консультации в процедуре включения IOMMU в вашем BIOS.

  2. Проверьте поддержку

    Убедитесь что конкретное устройство PCI определяется с возможностями SR-IOV. Приводимый пример перечисляет сетевые интерфейсы карты Intel 82576, которая поддерживает SR-IOV. Воспользуйтесь командой lspci для определения того, детектировано ли данное устройство.

    
    # lspci
    03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    		

    Отметим, что данный вывод был видоизменён удалением прочих устройств.

  3. Активировать Виртуальные функции

    Выполите следующую команду:

    
    # echo ${num_vfs} > /sys/class/net/enp14s0f0/device/sriov_numvfs
    		
  4. Сделать эти Виртуальные функции постоянными

    Чтобы сделать выбранную Виртуальную функцию не зависящей от перезагрузок, воспользуйтесь редактором по своему выбору чтобы создать некое правило udev аналогичное приводимому ниже, в котором вы определяете конкретный номер нужных вам VF (в этом примере 2), вплоть до того предела, который поддерживается данной картой сетевого интерфейса. В приводимом далее примере замените enp14s0f0 своим названием PF сетевого устройства и регулируется установленным ENV{ID_NET_DRIVER} значением для установления соответствия тому драйверу, который применяется:

    
    # vim /etc/udev/rules.d/enp14s0f0.rules
    
    ACTION=="add", SUBSYSTEM=="net", ENV{ID_NET_DRIVER}=="ixgbe", ATTR{device/sriov_numvfs}="2"
    		

    Это будет гарантировать, что данное свойство включается во время загрузки.

  5. При помощи команды Проверьте полученные новые Виртуальные функции

    lspci выведите перечень только что добавленных Виртуальных функций, подключённых к сетевому устройству Intel 82576 (как альтернатива, воспользуйтесь grep для поиска Virtual Function чтобы определить какие из устройств поддерживают Виртуальные функции.)

    
    # lspci | grep 82576
    0b:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    0b:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    0b:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.6 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:10.7 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:11.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:11.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:11.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:11.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    0b:11.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    		

    Саи идентификатор для данного устройства PCI определяется в параметре -n вашей команды lspci. Все Физические функции обозначаются как 0b:00.0 и 0b:00.1. Все виртуальные функции имеют в своём определении Virtual Function.

  6. Убедитесь в наличии устройств с помощью virsh

    Служба libvirt должна распознать ваше устройство прежде чем добавить некое устройство в виртуальную машину. libvirt применяет аналогичную выводу lspci нотацию. Все симвлы пунктуации : и . в выводе lspci заменяются на нижнее подчёркивание (_).

    Воспользуйтесь командой virsh nodedev-list и командой grep для фильтрации искомого сетевого устройства Intel 82576 в перечне всех доступных устройств хоста. Значением фильтра для поиска сетевых устройств Intel 82576 в данном примере является 0b. Оно может быть другим для вашей системы и может иметь результатом дополнительные устройства.

    
    # virsh nodedev-list | grep 0b
    pci_0000_0b_00_0
    pci_0000_0b_00_1
    pci_0000_0b_10_0
    pci_0000_0b_10_1
    pci_0000_0b_10_2
    pci_0000_0b_10_3
    pci_0000_0b_10_4
    pci_0000_0b_10_5
    pci_0000_0b_10_6
    pci_0000_0b_11_7
    pci_0000_0b_11_1
    pci_0000_0b_11_2
    pci_0000_0b_11_3
    pci_0000_0b_11_4
    pci_0000_0b_11_5
    		

    В приводимом перечне должны присутствовать адреса PCI для искомых Виртуальной функции и Физической функции.

  7. Получите детализацию устройства посредством virsh

    Значение pci_0000_0b_00_0 является одной Физической функцией, а pci_0000_0b_10_0 является самым первым, относящимся к Виртуальной функции для этой Физической функции. Примените команду virsh nodedev-dumpxml для получения подробностей об устройстве для обоих аппаратных средств.

    
    # virsh nodedev-dumpxml pci_0000_03_00_0
    <device>
      <name>pci_0000_03_00_0</name>
      <path>/sys/devices/pci0000:00/0000:00:01.0/0000:03:00.0</path>
      <parent>pci_0000_00_01_0</parent>
      <driver>
        <name>igb</name>
      </driver>
      <capability type='pci'>
        <domain>0</domain>
        <bus>3</bus>
        <slot>0</slot>
        <function>0</function>
        <product id='0x10c9'>82576 Gigabit Network Connection</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
        <capability type='virt_functions'>
          <address domain='0x0000' bus='0x03' slot='0x10' function='0x0'/>
          <address domain='0x0000' bus='0x03' slot='0x10' function='0x2'/>
          <address domain='0x0000' bus='0x03' slot='0x10' function='0x4'/>
          <address domain='0x0000' bus='0x03' slot='0x10' function='0x6'/>
          <address domain='0x0000' bus='0x03' slot='0x11' function='0x0'/>
          <address domain='0x0000' bus='0x03' slot='0x11' function='0x2'/>
          <address domain='0x0000' bus='0x03' slot='0x11' function='0x4'/>
        </capability>
        <iommuGroup number='14'>
          <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
          <address domain='0x0000' bus='0x03' slot='0x00' function='0x1'/>
        </iommuGroup>
      </capability>
    </device>
    
    # virsh nodedev-dumpxml pci_0000_03_11_5
    <device>
      <name>pci_0000_03_11_5</name>
      <path>/sys/devices/pci0000:00/0000:00:01.0/0000:03:11.5</path>
      <parent>pci_0000_00_01_0</parent>
      <driver>
        <name>igbvf</name>
      </driver>
      <capability type='pci'>
        <domain>0</domain>
        <bus>3</bus>
        <slot>17</slot>
        <function>5</function>
        <product id='0x10ca'>82576 Virtual Function</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
        <capability type='phys_function'>
          <address domain='0x0000' bus='0x03' slot='0x00' function='0x1'/>
        </capability>
        <iommuGroup number='35'>
          <address domain='0x0000' bus='0x03' slot='0x11' function='0x5'/>
        </iommuGroup>
      </capability>
    </device>
    		

    Данный пример добавляет необходимую Виртуальную функцию pci_0000_03_10_2 в определяемую виртуальную машину на шаге 8. Обратим внимание на параметры bus, slot и function: они необходимы для добавления данного устройства.

    Скопируйте эти параметры во временный файл XML, скажем, такой как /tmp/new-interface.xml.

    
    <interface type='hostdev' managed='yes'>
      <source>
        <address type='pci' domain='0x0000' bus='0x03' slot='0x10' function='0x2'/>
      </source>
    </interface>
    		
    [Замечание]Замечание

    Когда запускается данная виртуальная машина, она должна видеть некое сетевое устройство с определяемым типом, который предоставляется его физическим адаптером, причём с настроенным MAC адресом. Это MAC адрес будет оставаться неизменным при перезагрузках хоста и гостя.

    Следующий пример <interface> отображает необходимый синтаксис для опциональных элементов <mac address>, <virtualport> и <vlan>. На практике применяйте либо значение элемента <vlan>, либо значение элемента <virtualport>, а не оба одновременно, как это отображено в приводимом примере:

    
    ...
      <devices>
        ...
        <interface type='hostdev' managed='yes'>
          <source>
            <address type='pci' domain='0' bus='11' slot='16' function='0'/>
          </source>
          <mac address='52:54:00:6d:90:02'>
          <vlan>
             <tag id='42'/>
          </vlan>
          <virtualport type='802.1Qbh'>
            <parameters profileid='finance'/>
          </virtualport>
        </interface>
        ...
    </devices>
    		

    Если вы не определили MAC адрес, он будет выработан автоматически. Значение элемента <virtualport> применяется только при соединении с неким аппаратным коммутатором 802.11Qbh. Значение элемента <vlan> будет прозрачно помещено в устройство гостя в соответствующий VLAN с тегом 42.

  8. Добавление этой Виртуальной функции в вашу виртуальную машину

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

    
    virsh attach-device MyGuest /tmp/new-interface.xml --live --config
    		

    Определение опции --live в virsh attach-device подключает необходимое новое устройство к такому исполняемому гостю. Применение опции --config обеспечит что такое новое устройство остаётся доступным после последующих перезапусков гостя.

    [Замечание]Замечание

    Jgwbz --live применяется только когда этот гость исполняется. virsh вернёт некую ошибку если данная опция --live применятеся при не исполняемом госте.

Данная виртуальная машина определяет некую новую карту сетевого интерфейса. Это новая карта является той самой Виртуальной функцией данного устройства SR-IOV.

  Настройка назначения PCI с устройствами SR-IOV

Сетевые карты SR-IOV предоставляют множество VF, каждая из еоторых может индивидуадльно назначаться какой- то гостевой виртуальной машине с применнеием назначения устройства PCI. Получив назначение, каждая из них ведёт себя как некое поноправное физическое сетевое устройство. Это позволяет множеству гостевых виртуальных машин получать преимущество производительнсоти от прямого назначения устройства PCI, причём при этом используется только один слот в его физической машине хоста.

Эти VF могут назначаться гостевым виртуальным машинам индивидуальным образом при помощи соответствующего элемента <hostdev>. Однако VF сетевых устройств SR-IOV не имеют постоянных уникальных MAC адресов, которые вызывают проблемы когда сетевый установки таких гостевых виртуальных машин нуждаются в изменении настроек при каждой перезагрузке самой физической машины хоста. Для исправления этого вам требуется установить необходимый MAC адрес прежде чем назначать такую VF этой физической машине хоста после каждой перезагрузки рассматриваемой гостевой виртуальной машины. Чтобы назначать такой MAC адрес, а также для прочих опций, следуйте приводимой далее процедуре:

 

Процедура 17.9. Настройка MAC адресов, vLAN и виртуальных портов для назначения устройств PCI в SR-IOV

Имеющийся элемент <hostdev> не может применяться для специфичных к функции элементов, таких как назначение адреса MAC, назначение идентификатора тега VLAN, либо назначение виртуального порта, так как все элементы <mac>, <vlan> и <virtualport>, которые не являются допустимыми детьми для <hostdev>. Вместо этого, данные элементы могут применяться с имеющимся типом интерфейса hostdev: <interface type='hostdev'>. Такой тип устройства ведёт себя как некий гибрид <interface> и <hostdev>. Как результат, перед назначением такого устройства PCI для этой гостевой виртуальной машины, libvirt инициализирует то специфичное для сети оборудование/ коммутатор, который указан (такие, как установка MAC адреса, установка тега VLAN, либо связи с неким коммутатором 802.1Qbh) в файле настройки XML данной гостевой виртуальной машины. Для получения информации об установках значения тега VLAN ознакомьтесь с разделом 18.16 Настройка тегов VLAN.

  1. Выборка информации

    Чтобы применить <interface type='hostdev'>, вам требуется иметь некую сетевую карту с возможностями SR-IOV, оборудование физической машины хоста, которое поддерживает расширения либо Intel VT-d, либо AMD IOMMU, а также вы должны знать тот адрес PCI вашей VF, которую вы желаете назначать.

  2. Остановите свою гостевую виртуальную машину

    При помощи команды virsh shutdown AppA.html#11">остановите свою гостеую виртуальную машину (в нашем случае именуемую как guestVM).

    
    # virsh shutdown guestVM
    		
  3. Для внесения изменений откройте соответствующий файл XML

    Выполните команду virsh save-image-edit чтобы открыть необходимый для редактирования файл (для получения дополнительной информации обратитесь к разделу 21.7.5 Изменение настрек вашей гостевой виртуальной машины) с опцией --running. В данном примере названием вашего файла настроки является guestVM.xml.

    
    # virsh save-image-edit guestVM.xml --running
    		

    Этот файл guestVM.xml откроется в вашем редакторе по умолчанию.

  4. Изменение вашего файла XML

    Обновите свой файл настройки guestVM.xml чтобы получить некую запись <devices> со следующим содержимым:

     

    Рисунок 17.11

    
    <devices>
      ...
      <interface type='hostdev' managed='yes'>
        <source>
          <address type='pci' domain='0x0' bus='0x00' slot='0x07' function='0x0'/> <!--эти значения также могут быть десятичными-->
        </source>
        <mac address='52:54:00:6d:90:02'/>
    <!--установки mac адреса-->
        <virtualport type='802.1Qbh'>
    <!--установки виртуального порта для коммутатора 802.1Qbh-->
          <parameters profileid='finance'/>
        </virtualport>
        <vlan>
    <!--установки тега vlan-->
          <tag id='42'/>
        </vlan>
      </interface>
      ...
    </devices>
    		Образец домена XML для интерфеса типа hostdev

    Заметим, что если вы не предоставите какой- то MAC адрес, он будет выработан автоматически, в точности как если бы это было с любым другим типом устройства интерфейса, значение элемента <virtualport> используется только если вы подключениы к некому аппаратному коммутатору 802.11Qgh. Коммутаторы 802.11Qbg (также именуемые как "VEPA") в настоящее время не поддерживаются.

  5. Перезапустите свою гостевую виртуальную машину

    Выполните команду virsh start для перезапуска своей гостевой виртуальной машины, которую вы остановили на шаге 2. Для получения дополнительной информации обратитесь к разделу Запуск, приостановка и возобновление виртуальной машины.

    
    # virsh start guestVM
    		

    Когда ваша гостевая виртуальная машина запустится, она обнаружит предоставленное её сетевое устройство со стороны адаптера своей физической машины хоста, причём с настроенным MAC адресом. Этот MAC адрес будет оставаться неизменным при перезагрузках гостевой виртуальной машины и физической машины хоста.

  Установка назначения устройства PCI из пула виртуальных функций SR-IOV

Жёсткое кодирование необходимых адресов PCI определённых Виртуальных функций (VF) в конфигурации гостя имеет два серъёзных ограничения:

  • Заявленная VF должна быть доступна всякий раз при запуске данной гостевой виртуальной машины. По этой причине ваш администратор должен постоянно назначать каждую VF отдельной гостевой виртуальной машине (или изменять соответствующий файл настройки для каждой гостевой виртуальной машины чтобы определять не используемые в данный момент PCI адреса VF при каждом запуске гостевой виртуальной машины).

  • Если определённая гостевая виртуальная машина перемещается на другую физическую машину хоста, такая физическая машина хоста должна иметь в точности то же самое оборудование, при этом размещённое в тех же самых местах в своей шине PCI (или же конфигурация такой гостевой машины должна бытьизменена перед её запуском).

Имеется возможность избежать обе эти проблемы путём создания сетевой среды libvirt с неким пулом устройств, который содержит все имеющиеся VF устройства SR-IOV. Когда это сделано, настройте свою гостевую виртуальную машину на обращение к этой сетевой среде. При каждом запуске вашего гостя будет выделяться некая отдельная VF из имеющегося пула и назначаться вашей гостевой виртуальной машине. Когда ваша гостевая виртуальная машина останавливается, такая VF будет возвращаться в имеющийся пул для её использования другими гостевыми виртальными машинами.

 

Процедура 17.10. Создание пула устройств

  1. Остановите свою гостевую виртуальную машину

    При помощи команды virsh shutdown остановите свою гостеую виртуальную машину здесь мы именуем её как guestVM).

    
    # virsh shutdown guestVM
    		
  2. Создайте файл настройки

    Воспользуйтесь предпочитаемым вами редактором, создайте некий файл XML (например, с названием passthrough.xml в своёмс каталоге /tmp. Убедитесь в том, что вы заменили pf dev='eth3' названием сетевого устройства своей собственной Физической функции (PF, Physical Function) устройства SR-IOV.

    Ниже приводтся пример сетевого определения, который сделает доступным некий пул всех VF для определённого адаптера SR-IOV с его PF "eth3" в физической машине хоста:

     

    Рисунок 17.12

    
    <network>
    <name>passthrough</name> <!-- Это название создаваемого вами файла -->
      <forward mode='hostdev' managed='yes'>
        <pf dev='myNetDevName'/> <!-- Здесь используйте своё имя сетевого устройства для вашей PF оборудования SR-IOV -->
      </forward>
    </network>
    		
    Образец определения домена XML

  3. Загрузите полученный новый файл XML

    Введите следующую команду, заменив в ней /tmp/passthrough.xml своим названием и местоположением вашего файла XML, который вы создали на предыдущем шаге:

    
    # virsh net-define /tmp/passthrough.xml
    		
  4. Перезапустите этого гостя

    Выполните следующую команду, заменив passthrough.xml названием вашего файла XML, созданного на предыдущих шагах:

    
    # virsh net-autostart passthrough # virsh net-start passthrough
    		
  5. Перезапустите эту гостевую виртуальную машину

    Выполните команду virsh start для перезапуска своей гостевой виртуальной машины, которую вы остановили на первом шаге (в данном примере в качестве доменного имени такой гостевой виртуальной машины применяется guestVM). Для получения дополнительной информации обратитесь к разделу Запуск, приостановка и возобновление виртуальной машины.

    
    # virsh start guestVM
    		
  6. Инициализация проброса для устройств

    Хотя показано только одно устройство, libvirt автоматически выведет список всех связанных с этим PF VF при первом запуске гостевой виртуальной машины с определением интерфейса в своем домене XML как показано ниже:

     

    Рисунок 17.13

    
    <interface type='network'>
      <source network='passthrough'>
    </interface>
    		
    Образец домена XML для определения сетевого интерфейса

  7. Проверка

    Вы можете выполнить проверку исполнив команду virsh net-dumpxml passthrough после запуска вашего гостя, который использует эту сеть; вы получите вывод, аналогичный следующему:

     

    Рисунок 17.14

    
    <network connections='1'>
      <name>passthrough</name>
      <uuid>a6b49429-d353-d7ad-3185-4451cc786437</uuid>
      <forward mode='hostdev' managed='yes'>
        <pf dev='eth3'/>
        <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x1'/>
        <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x3'/>
        <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x5'/>
        <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x7'/>
        <address type='pci' domain='0x0000' bus='0x02' slot='0x11' function='0x1'/>
        <address type='pci' domain='0x0000' bus='0x02' slot='0x11' function='0x3'/>
        <address type='pci' domain='0x0000' bus='0x02' slot='0x11' function='0x5'/>
      </forward>
    </network>
    		
    Дамп содержимого проброса файла XML

  Ограничения SR-IOV

SR-IOV полностью проверен со следующими устройствами:

  • Intel® 82576NS Gigabit Ethernet Controller (драйвер igb)

  • Intel® 82576EB Gigabit Ethernet Controller (драйвер igb)

  • Intel® 82599ES 10 Gigabit Ethernet Controller (драйвер ixgbe)

  • Intel® 82599EB Gigabit Ethernet Controller (драйвер ixgbe)

Прочие SR-IOV могут работать, но не были ещё пока протестированы на момент данного выпуска. {Прим. пер.: если у вас есть интерес к SR-IOV GPU AMD FirePro S7150x2/ S7150, обратитесь к нам.}

Устройства USB

Данный раздел предоставляет команду, треюующиеся для обработки устройств USB.

  Назначение USB устройств гостевым виртуальным машинам

Большинство устройств, таких как веб камеры, считыватели карт, дисковые устройства, клавиатуры, мыши подключаются к компьютеру при помощи некоторого порта и кабеля USB. Имеется два способа передачи таких устройств в гостевую виртуальную машину:

  • С помощью проброса USB (passthrough) - требует чтобы данное устройство было физически подкдючено к той физической машине хоста, которая размещает данную гостевую виртуальную машину. В данном случае SPICE не требуется. Устройства USB в этом хосте могут быть переданы в гостя через командную строку или virt-manager. Обратитесь к Разделу 20.3.2 Подключение устройства USB в гостевую виртуальную машину для указаний относительно virt-manager. Отметим, что приведённые указания для virt-manager не применимы для подключаемых или отключаемых в горячем режиме устройств. Если вы желаете подключать/ или отключать по- горячему устройство USB, обратитесь к Процедура 21.4. Подключение устройств USB в горячем режиме для использоватея в гостевых виртуальных машинах.

  • С помощью перенаправления USB - re-direction USB является наилучшим вариантом в тех случаях, когда имеется некая физическая машина хоста, которая работает в каком- то центре обработки данных. Тот пользователь, который подключается в его/ её гостевой виртуальной машине со своей локальной машины или тонкого клиента. В данной локальной машине имеется некий клиент SPICE. Данный пользователь может подключать в своего тонкого клиента любое устройство USB, а клиент SPICE перенаправит это устройство в свою физическую машину хоста в центре обработки данных с тем, чтобы оно было использовано в той гостевой виртуальной машине, которая исполняется в этом тонком клиенте. Для получения инструкций под virt-manager обратитесь к Разделу 20.3.3 Перенаправление USB.

  Установка ограничения на перенаправление устройства USB

Для фильтрации определённых устройств при перенаправении передайте эти свойства фильтрации в -device usb-redir. Это свойство фильтрации получит некую строку правил фильтрации со следующим форматом правила:


<class>:<vendor>:<product>:<version>:<allow>
 	   

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

 

Пример 17.01. Образец ограничения перенаправления в гостевую виртуальную машину

  1. Подготовьте гостевую виртуальную машину.

  2. Добавьте следующую вставку кода в файл домена XML своей гостевой виртуальной машины:

    
    <redirdev bus='usb' type='spicevmc'>
      <alias name='redir0'/>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <redirfilter>
      <usbdev class='0x08' vendor='0x1234' product='0xBEEF' version='2.0' allow='yes'/>
      <usbdev class='-1' vendor='-1' product='-1' version='-1' allow='no'/>
    </redirfilter>
     	   
  3. Запустите свою гостевую виртуальную машину и убедитесь в изменении установок выполнив следующее:

    
    #ps -ef | grep $guest_name
    
    -device usb-redir,chardev=charredir0,id=redir0,/ filter=0x08:0x1234:0xBEEF:0x0200:1|-1:-1:-1:-1:0,bus=usb.0,port=3
    		
  4. Подключите некое устройство USB в физическую машину хоста и воспользуйтесь virt-manager для его подключения в соответствующую гостевую виртуальную машину.

  5. Кликните по USB device selection в полученном меню, что выведет следующее сообщение "Some USB devices are blocked by host policy" (некоторые USB устройства блокируются политикой хоста). Кликните OK для подтверждения и продолжения.

    Этот фильтр приступит к работе.

  6. Чтобы убедиться что данный фильтр прехватывает как надо проверку названий производителя USB и самого продукта, затем внестите такие изменения в XML домена своей физической машины хоста чтобы разрешить перенаправление USB.

    
    <redirfilter>
      <usbdev class='0x08' vendor='0x0951' product='0x1625' version='2.0' allow='yes'/>
      <usbdev allow='no'/>
    </redirfilter>
     	   
  7. Перезапустите эту гостевую виртуальную машину, затем воспользуйтесь virt-viewer для подключения к этой гостевой виртуальной машине. Данное устройство USB теперь переправляет обмен в эту гостевую виртуальную машину.

Настройка контроллеров устройств

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

 

Рисунок 17.15


...
<devices>
  <controller type='ide' index='0'/>
  <controller type='virtio-serial' index='0' ports='16' vectors='4'/>
  <controller type='virtio-serial' index='1'>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
  </controller>
  ...
</devices>
...
 	   
Пример домена XML для виртуальных контроллеров

Всякий контроллер имеет обязательный атрибут <controller type>, который должен быть одним из:

  • ide

  • fdc

  • scsi

  • sata

  • usb

  • ccid

  • virtio-serial

  • pci

Такой элемент <controller> имеет обязательный атрибут <controller index> являющийся десятичным целым, объясняющим в каком порядке его перечисляет контроллер шины (для применения в атрибутах элементов <address> контроллера). Когда в <controller type ='virtio-serial'> имеются два дополнительных необязательных атрибута (с названиями ports и vectors), которые управляют тем сколько устройств можно подключать через данный контроллер.

В случае, когда <controller type ='scsi'>, имеется необязательный атрибут модели model, который может иметь следующие значения:

  • auto

  • buslogic

  • ibmvscsi

  • lsilogic

  • lsisas1068

  • lsisas1078

  • virtio-scsi

  • vmpvscsi

В случае, когда <controller type ='usb'>, имеется необязательный атрибут модели model, который может иметь следующие значения:

  • piix3-uhci

  • piix4-uhci

  • ehci

  • ich9-ehci1

  • ich9-uhci1

  • ich9-uhci2

  • ich9-uhci3

  • vt82c686b-uhci

  • pci-ohci

  • nec-xhci

Отметим, что если данная шина USB требует указания в явном виде запрещения для вашей гостевой виртуальной машины, можно применить <model='none'>.

Для контроллеров, которые сами по сеье устройства в шине PCI или USB, можно определить некий необязательный элемент <address> для точной взаимосвязи данного контроллера с его шиной хозяина с той семантикой, которая показана в разделе 17.5 Установка адресов для устройств.

Некий необязательный субэлемент <driver> может определять специфичные для драйвера опции. В настоящее время он поддерживает только атрибут queues, котрый определяет общее число очередей для данного контроллера. Для наилучшей производительности рекомендуется определять значение, соответствующее имеющемуся числу vCPU.

Контроллеры, сопутствующие USB имеют некий необязательный субэлемент <master> для определения явной взаимосвязи такого контроллера его контроллеру хозяину. Сопутствующий контроллер находится на той же самой шине, что и его хозяин, поэтому значение index этого сопутствующего контроллера должно быть эквивалентным.

Вот некий пример XML, которым можно воспользоваться:

 

Рисунок 17.16


...
<devices>
  <controller type='usb' index='0' model='ich9-ehci1'>
    <address type='pci' domain='0' bus='0' slot='4' function='7'/>
  </controller>
  <controller type='usb' index='0' model='ich9-uhci1'>
    <master startport='0'/>
    <address type='pci' domain='0' bus='0' slot='4' function='0' multifunction='on'/>
  </controller>
  ...
</devices>
...
 	   
Пример домена XML для контроллеров USB

Контроллеры PCI имеют необязательный атрибут model со следующими возможными значениями:

  • pci-root

  • pcie-root

  • pci-bridge

  • dmi-to-pci-bridge

Для тех типов машин, которые предоставляют шину PCI в явном виде, контроллер pci-root с index='0' автоматически добавляется и его необходим для применения устройств PCI, pci-root не имеет адреса. Мосты PCI также автоматически добавляются если имеется более двух устройств для размещения в одной шине, предоставляемой model='pci-root', либо в случае, когда определён номер шины PCI со значением более нуля. Мосты PCI могут также задаваться вручную, однако их адреса должны ссылаться на шины PCI, предоставляемые уже определёнными контроллерами PCI. Оставление промежутков в индексации ваших контроллеров PCI может повлечь за собой неверную настройку. Следующий пример XML можно добавить в ваш раздел <devices>:

 

Рисунок 17.17


...
<devices>
  <controller type='pci' index='0' model='pci-root'/>
  <controller type='pci' index='1' model='pci-bridge'>
    <address type='pci' domain='0' bus='0' slot='5' function='0' multifunction='off'/>
  </controller>
</devices>
...
 	   
Пример домена XML для моста PCI

Для того типа машин, которые предоставляют в явном виде шину PCI Express (PCIe, например, все типы машин на основе набора микросхем Q35) автоматически добавляется контроллер pcie-root с index='0' в настройку вашего домена. pcie-root также не имеет адреса, однако он предоставляет 31 слот (с номерами 1-31) и может применяться только для устройств PCIe. Чтобы подключать стандартные устройства PCI в некую систему, которая имеет контроллер pcie-root, автоматически добавляется некий контроллер pci с model='dmi-to-pci-bridge'. Контроллер dmi-to-pci-bridge подключается к слоту PCIe (который в свою очередь предоставлен pcie-root) и сам по себе предоставляет 31 стандартных слотов PCI (которые не являются подключаемыми в горячем режиме). Чтобы иметь в своей гостевой системе подключаемые в горячем режиме слоты PCI, также будет автоматически создан некий контроллер pci-bridge и подключён к к одному из имеющихся слотов автоматически созданного контроллера dmi-to-pci-bridge; все гостевые устройства с адресами PCI, которые автоматически определены libvirt будут помещены в это устройство pci-bridge.

 

Рисунок 17.18


...
<devices>
  <controller type='pci' index='0' model='pcie-root'/>
  <controller type='pci' index='1' model='dmi-to-pci-bridge'>
    <address type='pci' domain='0' bus='0' slot='0xe' function='0'/>
  </controller>
  <controller type='pci' index='2' model='pci-bridge'>
    <address type='pci' domain='0' bus='1' slot='1' function='0'/>
  </controller>
</devices>
...
 	   
Пример домена XML для PCIe (PCI express)

Следующая конфигурация XML применяется для эмуляции USB 3.0 / xHCI:

 

Рисунок 17.19


...
<devices>
  <controller type='usb' index='3' model='nec-xhci'>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x0f' function='0x0'/>
    </controller>
  </devices>
...
 	   
Пример домена XML для PCIe (PCI express)

Установка адресов для устройств

Многие устройства имеют необязательный субэлемент <address> который применяется для того чтобы указать где данное устройство помещается в вашей виртуальной шине представленной назначаемой гостевой виртуальной машине. Если некий адрес (или любой необязательный атрибут внутри какого- то адреса) опущен во вводе, libvirt ваработает соответствующий адрес; однако, в случае, когда требуется дополнительный контроль за схемой, требуется некий адрес в явном виде. За примерами домена XML устройства, которые содержат некий элемент <address> обратитесь к Рисунку 17-9, Пример XML для назначения устройства PCI.

Всякий адрес имеет обязательный атрибут type, который описывает на какой шине находится данное устройство. Собственно выбор того, какой адрес применять для заданного устройства составляется из самих частей конкретного устройства и имеющейся архитектуры гостевой виртуальной машины. Например, устройство <drive> применяет type='drive', в то время как устройство <console> использовало бы type='pci' в архитектурах гостевой виртуальной машины i686 или x86_64. Всякий тип ажреса имеет последующие не обязательные атрибуты, которые управляют где в конкретной шине это устройство будет помещено, как это описывается в приводимой далее таблице:

Таблица 17-1. Поддерживаемые типы адреса устройства
Тип адреса Описание

type='pci'

Адреса PCI имеют следующие дополнительные артибуты:

  • домен (шестнадцатеричное целое из бвух байт, в настоящее время не сивользуется в qemu)

  • шина (некое шестнадцатеричное значение между 0x0 и 0xff включительно)

  • слот (некое шестнадцатеричное значение между 0x0 и 0xff включительно)

  • функция (значение между 0 и 7 включительно)

  • управление регулированием множественности функций в бите множественности функция для определённого слота/ функции в соответствующем регистре управления PCI. По умолчанию он установлен в значение 'off', однако должен быть установлен в 'on' для фуекции 0 того слота, который будет применять множество функций.

type='drive'

Адрес drive имеет следующие дополнительные артибуты:

  • контроллер (номер контроллера из двух цифр)

  • шина (номер шины из двух цифр)

  • цель (номер шины из двух цифр)

  • элемент (номер элемент из двух цифр в определённой шине)

type='virtio-serial'

Всякий адрес virtio-serial имеет следующие дополнительные артибуты:

  • контроллер (номер контроллера из двух цифр)

  • шина (номер шины из двух цифр)

  • слот (номер слота из двух цифр внутри определённой шины)

type='ccid'

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

  • шина (номер шины из двух цифр)

  • атрибут слота (номер слота из двух цифр внутри заданной шины)

type='usb'

Адреса USB имеют следующие дополнительные артибуты:

  • шина (некое шестнадцатеричное значение между 0x0 и 0xfff включительно)

  • порт (до четырёх октетов в нотации с разделением точкой, таких как 1.2 или 2.1.3.1)

type='isa'

Адреса ISA имеют следующие дополнительные артибуты:

  • iobase

  • irq

Генератор случайного номера устройства

Для безопасности операционной системы очень важны генераторы случайных чисел. Для безопасности виртуальных операционных систем Red Hat Enterprise Linux 7 содержит virtio-rng, некое устройство генерации случайного номера виртуального оборудования, которое может предоставлять соответствующему гостю новую меру беспорядка по запросу.

В имеющейся физической машине хоста представленный аппаратный интерфейс RNG создает символьное устройство в /dev/hwrng, которое можно открыть и затем считывать для забора меры беспорядка со своей машины хоста. В содружестве с демоном rngd значение меры беспорядка с физической машины хоста может быть передано по маршруту в соответствующий /dev/random гостевой виртуальной машины, который является самым первым источником случайных чисел.

Применение генератора случайных чисел в особенности полезно когда некое устройство, например, клавиатура, мышт и прочие устройства, не являются достаточными для выработки достаточной меры беспорядочности в вашей гостевой виртуальной машине. такое виртуальное устройство генерации случайного числа позволяет своей физической машине хоста пробрасывать меру беспорядка в операционные системы гостевых виртуальных машин. Данная процедура может быть осуществлена либо через командную строку, либо посредством интерфейса virt-manager. Для получения дополнительной информации по virtio-rng обратитесь к Red Hat Enterprise Linux Virtual Machines: Access to Random Numbers Made Easy.

 

Процедура 17.11. Реализация virtio-rng при помощи Диспетчера виртуальных машин

  1. Остановите гостевую виртуальную машину.

  2. Выберите нужную гостевую виртуальную машину и из её меню Edit остановитесь на Virtual Machine Details чтобы открыть окно Details для специфицируемой гостевой виртуальной машины.

  3. Кликните по кнопке Add Hardware.

  4. В окне Add New Virtual Hardware выберите RNG для открытия окна Random Number Generator.

     

    Рисунок 17-20


    Окно генератора случайного номера

    Введите нужные параметры и кликните RNG по завершению. Все параметры объясняются в разделе Элементы virtio-rng.

 

Процедура 17.12. Реализация virtio-rng с применением инструментов командной строки

  1. Остановите гостевую виртуальную машину.

  2. Воспользовавшись командой virsh edit domain-name откройте необходимый файл XML для нужной вам гостевой виртуальной машины.

  3. Измените соответствующий элемент <devices> с тем, чтобы он содержал следующее:

     

    Рисунок 17.21

    
    ...
    <devices>
      <rng model='virtio'>
        <rate period='2000' bytes='1234'/>
        <backend model='random'>/dev/random</backend>
        <!-- ИЛИ -->
        <backend model='egd' type='udp'>
          <source mode='bind' service='1234'/>
          <source mode='connect' host='1.2.3.4' service='1234'/>
        </backend>
      </rng>
    </devices>
    ...
     	   
    Устройство генерации случайного номера

Данное устройство генерации случайного номера допускает следующие атрибуты и элементы XML:

 

Элементы virtio-rng

  • <model> - Необходимый атрибут model описывает какой тип устройства RNG предоставляется.

  • <backend model> - Элемент backend определяет соответствующий источник меры беспорядка, который будет применяться в соответствующем госте. Сама модель источника определяетмя с помощью атрибута model. Поддерживаемые модели источника включают в свой состав 'random' и 'egd'.

    • <backend model='random'> - Элемент backend определяет соответствующий источник неблокируемого символьного устройства иеры беспорядка в качестве ввода. Примерами таких устройств являются /dev/random /dev/urandom. Необходимое название файла определяется как сожержимое данного элемента backend. Когда не определено никакое название файла, применяется определённое по умолчанию в гипервизоре.

    • <backend model='egd'> - Этот сервер подключается в источник с применением проткола EGD. Такой источник определяется как символьнок устройство. Для получения дополнительной информации обратитесь к дркументации по символьному интерфейсу физической машины хоста.

Назначение устройств GPU

Red Hat Enterprise Linux 7 поддерживает назначение PCI устройства для следующих GPU устро ств как не графических устройств:

  • nVidia Quadro серий K-, M- и P- (модели, начинающиеся с серии 2000)

  • nVidia GRID серий K- M- {Прим. пер.: и P-}

  • nVidia Tesla серий K- M- {Прим. пер.: а также P- и V-}

  • {Прим. пер.: а также AMD FirePro S7150x2/ S7150, подробнее у нас}

В настоящее время в определённую виртуальную машину может быть подключено до двух GPU в дополнение к одному стандартному интерфейсу эмуляции VGA. Эмулируемый VGA применяется для предварительной загрузки и изоляции, а nVidia GPU вступает в игру после загрузки графических драйверов nVidia.

Данная процедура определяет неоходимое устройство в lspci, отсоединяет его от физической машины и затем подключает его к соответствтующей гостевой виртуальной машине.

  1. Включите поддержку IOMMU в ядре физической машины хоста

    Для систем Intel VT-d это делается путём добавления параметров intel_iommu=on и iommu=pt в её командную строку ядра. Для систем AMD-Vi это опция amd_iommu=pt. Для включения данной опции измените или добавьте необходимую строку GRUB_CMDLINX_LINUX в файле настройки /etc/sysconfig/grub следующим образом:

    
    GRUB_CMDLINE_LINUX="rd.lvm.lv=vg_VolGroup00/LogVol01 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_VolGroup_1/root vconsole.keymap=us $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb quiet intel_iommu=on iommu=pt"
     	   
    [Замечание]Замечание

    Для получения дополнительной информации по IOMMU обратитесь к Дополнению D. Работа с группами IOMMU .

  2. Сгенерируйте новую настройку начального загрузчика

    Регенерируйте настройку своего начального загрузчика с помощью grub2-mkconfig чтобы включить установленные опции, исполнив следующую команду:

    
    # grub2-mkconfig -o /etc/grub2.cfg
    		

    Заметим, что если вы применяете хост на основе UEFI, целью должен быть /etc/grub2-efi.cfg.

  3. Перезагрузите физическую машину ввашего хоста

    Чтобы все изменённые опции вступили в действие, перезагрузите физическую машину своего хоста с помощью следующей команды:

    
    # reboot
    		
 

Процедура 17.13. Исключение определённого устройства GPU из связываения его с драйвером физической машины хоста

  1. Определение одреса на шине PCI

    Чтобы определить установленный адрес шины PCI и идентификатор определённого устройства, исполните следующую команду lspci. В данном примере применяется VGA контроллер подобный карте Quadro или GRID следующим образом:

    
    # lspci -Dnn | grep VGA
    0000:02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK106GL [Quadro K4000] [10de:11fa] (rev a1)
    		

    {Прим. пер.: рекомендуем слегка расширенный grep -A 2 -E "(VGA| 3D)". Для установки pciutils воспользуйтесь yum -y install pciutils} Результат поиска выведает что PCI адрес данного устройства установлен в значение 0000:02:00.0, а идентификатором PCI для данного устройства является 10de:11fa

  2. Предотвратите применение необходимого вам устройства GPU от его епстественного использования физической машиной хоста

    Чтобы уберечь использование настраиваемого устройства GPU натуральным драйвером физической машины хоста вы можете применить идентификатор PCI с имеющимся драйвером pci-stub. Для этого добавьте в конец GRUB_CMDLINX_LINUX файла настройки, расположенного в /etc/grub2-efi.cfg, следующую дополнительную опцию:

    
    pci-stub.ids=10de:11fa
    		

    Для добавления дополнительных идентификаторов PCI в pci-stub отделяйте их запятой. {Прим. пер.: также рекомендуем перечислить устройства GPU в чёрном списке:}

    
    ls /etc/modprobe.d/blacklist.conf
    echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
    echo "blacklist nvidia" >> /etc/modprobe.d/blacklist.conf
    echo "blacklist radeon" >> /etc/modprobe.d/blacklist.conf
    cat /etc/modprobe.d/blacklist.conf
    		
  3. Регенерируйте настройку своего начального загрузчика с помощью grub2-mkconfig чтобы включить установленные опции, исполнив следующую команду:

    
    # grub2-mkconfig -o /etc/grub2.cfg
    		

    Заметим, что если вы применяете хост на основе UEFI, целью должен быть /etc/grub2-efi.cfg.

  4. Перезагрузите физическую машину ввашего хоста

    Чтобы все изменённые опции вступили в действие, перезагрузите физическую машину своего хоста с помощью следующей команды:

    
    # reboot
    		

Для последующей оценки данного устройтсва можно применять команды virsh. Однако, чтобы применять virsh со своим устройством, вам понадобится преобразовать полученный адрес шины PCI в совместимый с libvirt формат, добавив префикс pci_ преобразовав все разделители в подчёркивания. В данном примере наш адрес libvirt устройства PCI 0000:02:00.0 становится pci_0000_02_00_0. Опция nodedev-dumpxml предоставляет дополнительную информацию для выбранного устройствва следующим образом:

 

Рисунок 17.22


		

# virsh nodedev-dumpxml pci_0000_02_00_0

<device>
  <name>pci_0000_02_00_0</name>
  <path>/sys/devices/pci0000:00/0000:00:03.0/0000:02:00.0</path>
  <parent>pci_0000_00_03_0</parent>
  <driver>
    <name>pci-stub</name>
  </driver>
  <capability type='pci'>
    <domain>0</domain>
    <bus>2</bus>
    <slot>0</slot>
    <function>0</function>
    <product id='0x11fa'>GK106GL [Quadro K4000]</product>
    <vendor id='0x10de'>NVIDIA Corporation</vendor>
<!-- обратите внимание на эту часть -->
    <iommuGroup number='13'>
      <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
      <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/>
    </iommuGroup>
    <pci-express>
      <link validity='cap' port='0' speed='8' width='16'/>
      <link validity='sta' speed='2.5' width='16'/>
    </pci-express>
  </capability>
</device>
		
Адаптация файла XML под GPU - Образец

Особенно важным в данном выводе является элемент <iommuGroup>. iommuGroup указывает тот набор устройств, который рассматривается как изолированный от прочих устройств благодаря возможностям IOMMU и топологии шины PCI. Все имеющиеся устройства конечных точек внутри iommuGroup (которые являются устройствами, не входящими в перечень портов корня PCIe, мостов или портов коммутации) необходимо вывести из состава имеющихся естественных драйверов хоста чтобы сделать возможным их назначение кокому- нибудь гостю. В приводимом выше примере наша группа состоит из нужного нам устройства GPU (0000:02:00.0), а также из комплектного с ним аудио устройствва (0000:02:00.1). Для получения дополнительной информации обратитесь к Дополнению D. Работа с группами IOMMU.

[Замечание]Замечание

Назначение аудио функций nVidia не поддерживается из- за аппаратных проблем с наследуемой поддержкой прерываний. Чтобы назначить данное GPU какому- то гостю, имеющаяся аудио- функция должна быть вначале отсоединена от естественных драйверов хоста. Это можно выполнить либо при помощи lspci для отыскания идентификатора PCI данного устройства и добавления его в опцию pci-stub.ids, или динамически при помощи опции virsh nodedev-detach. Например:


# virsh nodedev-detach pci_0000_02_00_1
Device pci_0000_02_00_1 detached
		

Аудио функция GPU обычно бесполезна без самого GPU, поэтому настоятельно рекомендуется вместо этого применять опцию pci-stub.ids.

Данное GPU может быть подключено к вашей ВМ с применением virt-manager или virsh, причём либо прямым изменением соответствующего XML этой ВМ (virsh edit [domain]), либо подключая это GPU в необходимый домен посредством virsh attach-device. Если вы применяете команду virsh attach-device, вначале понадобится создать некий фрагмент XML для данного устройства, например, следующим образом:

 

Рисунок 17.23


		

<hostdev mode='subsystem' type='pci' managed='yes'>
  <driver name='vfio'/>
  <source>
    <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
  </source>
</hostdev>
		
Файл XML для подключения GPU - Образец

Сохраните это файл и исполните virsh attach-device [domain] [file] --persistent чтобы включить необходимый XML в настройку своей ВМ. Отметим, что такое назначаемое GPU добавляется дополнительно к уже имеющемуся эмулируемому графическому устройству в данной гостевой виртуальной машине. Такое назначаемое GPU обрабатывается в качестве вторичного графического устройства в такой ВМ. Назначение в качестве первичного графического устройства не поддерживается и эмулируемые графические устройства в XML такой ВМ не следует удалять.

[Замечание]Замечание

При использовании некоторого назначенного GPU nVidia в таком госте поддерживаются только драйверы nVidia {Прим. пер.: у AMD для самого MxGPU это драйвер с открытым исходным кодом, а в гостевых машинах используются проприетарные драйверы}. Прочие драйверы могут не работать и выдавать ошибки. Для гостя Red Hat Enterprise Linux 7 драйвер nouveau может быть помещён в чёрный список при помощи опции modprobe.blacklist=nouveau в самой командной строке ядра при установке. {Прим. пер.: также обращаем внимание на своё замечание по изменению файла /etc/modprobe.d/blacklist.conf на втором шаге Продедуры 1713.} Для дополнительной информации по прочим гостевым виртуальным машинам обратитесь к специфичной для этих операционных систем документаций.

При настройке Xorg для использования с назначаемым GPU в каком- то госте KVM, следует добавить соответствующую опцию BusID в xorg.conf для определения необходимого адреса гостя даннго GPU. К примеру, в рамках определения нашего гостя применяется следующий адрес шины PCI нашего GPU (он может отличаться от полученного в хосте адреса):


# lspci | grep VGA
00:02.0 VGA compatible controller: Device 1234:1111
00:09.0 VGA compatible controller: NVIDIA Corporation GK106GL [Quadro K4000] (rev a1)
		

В данном примере мы получаем адрес 00:09.0. После этого изменяется файл /etc/X11/xorg.conf чтобы добавить в него обозначенную ниже запись.


Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BusID          "PCI:0:9:0"
EndSection
 	   

В зависимости от присутствующей гостевой операционной системы при соответствующем загруженном драйвере nVidia {AMD}, такой гость может поддерживать как эмулируемую графику, так и назначенную графику одновременно или может запретить имеющуюся эмулируемую графику. Отметим, что доступ к кадровому буферу такой назначенной графики не предоставляется такими инструментами как virt-manager. Если такая назначенная GPU не подключена к физическому дисплею, для доступа к GPU рабочего места могут понадобиться удалённые решения на основе гостя. {Прим. пер.: также может оказаться необходимой настройка EDID, обращайтесь к нам за услугами по настройке и сопровождению.} Как и все назначения устройств PCI, миграция гостя с назначенным GPU не поддерживается и владение всяким GPU находится в исключительном ведении отдельного гостя. В зависимости от имеющейся операционной системы гостя может осуществляться поддержка горячего подключения GPU.