Pci passthrough что это
Оригинал: "Linux virtualization and PCI passthrough"
Автор: M. Tim Jones
Дата публикации: 13 Oct 2009
Перевод: Н.Ромоданов
Дата перевода: март 2010 г.
Краткое содержание: Процессоры постоянно совершенствуются с целью повышения производительности работы в виртуальной среде, а как обстоят дела с вводом/выводом? Познакомьтесь с одним новшеством, связанным с вводом/выводом, которое улучшает производительность и называется сквозным доступом к устройству (или шине PCI). Это новшество повышает производительность устройств PCI благодаря аппаратной поддержке, реализованной фирмами Intel (VT-D) и AMD (IOMMU).
Когда платформа используется одновременно двумя или большим количеством операционных систем с целью достичь более эффективного использования ресурсов, то говорят о платформенной виртуализации. Но платформа подразумевает больше, чем просто процессор: она включает в себя также другие важные элементы, которые образуют платформу, например, устройства хранения данных, сетевое оборудование и другие аппаратные ресурсы. Некоторые аппаратные ресурсы, такие как процессор или устройства хранения данных, виртуализировать просто, а другие, такие как видео-адаптер или последовательный порт, плохо виртуализирутся. В технологии сквозного доступа к устройствам PCI (PCI passthrough) предоставлены средства, позволяющие использовать ресурсы второго вида эффективно в тех случаях, когда их совместное использование невозможно или нецелесообразно. В настоящей статье рассматривается понятие сквозного доступа (passthrough), обсуждается его реализация в гипервизорах, а также рассматриваются те особенности реализации гипервизоров, благодаря которым осуществляется поддержка этой самой новейшей технологии.
Сквозной доступ к устройствам
Как видно из двух вариантов эмуляции устройств, приведенных выше, есть некоторая цена, которую нужно заплатить за совместное использование устройств. Накладные расходы существуют независимо от того, осуществляется эмуляция устройств в гипервизоре или в пользовательском пространстве в отдельной виртуальной машине. Эти накладные расходы существуют до тех пор, пока устройство будет доступно одновременно нескольким гостевым операционным системам. Если совместное использование устройств не требуется, то есть более эффективные способы доступа к таким устройствам.
Итак, с самой общей точки зрения сквозной доступ к устройству является методикой, представляющей собой изоляцию устройств для конкретной гостевой операционной системы таким образом, что это устройство может использоваться исключительно этой гостевой системой (см. рис. 3). Но в чем здесь выгода? Очевидно, что существует целый ряд причин, по которым целесообразно использовать сквозной доступ к устройству. Двумя наиболее важными причинами являются повышение производительности и предоставление исключительного доступа к устройству, которое по сути не должно использоваться совместно.
Рис.3. Сквозной доступ внутри гипервизора
При использовании сквозного доступа к устройству можно достичь производительности, почти равной производительности самого устройства. Это идеально для сетевых приложений (или тех, в которых большой объем ввода/вывода на диск), в которых не используется виртуализация из-за отсутствия согласованности с гипервизором (несогласованность с драйвером в гипервизоре) и снижения производительности (из-за эмуляции в гипервизоре пользовательского пространства). Но назначение устройств конкретным гостевым системам также выгодно в случае, если эти устройства нельзя использовать одновременно несколькими системами. Например, если в системе есть нескольких видеоадаптеров, то их можно индивидуально закрепить за каждым конкретным гостевым доменом.
Наконец, могут быть специализированные устройства PCI, которые может использовать только один гостевой домен, или устройства, которые не поддерживаются гипервизором и, следовательно, должны быть перенесены в гостевую систему. Для конкретного домена могут быть выделены отдельные USB порты, либо для конкретной гостевой системы может быть выделен последовательный порт (который, сам по себе, не может использоваться одновременно несколькими системами).
2. Отбираем видеокарту у драйвера
Ищем нужные устройства и смотрим какие драйвера их используют.
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2)
Kernel driver in use: nouveau
Kernel modules: nvidiafb, nouveau
04:00.1 Audio device [0403]: NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1)
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
Добавляем модули VFIO, чтобы они подгружались при загрузке.
Настраиваем модуль VFIO, чтобы он перехватывал устройства, не давая загрузиться основным драйверам. При необходимости добавляем в черный список, основной драйвер.
0. Проверяем, что железо поддерживает IOMMU
Двигаемся дальше
Виртуализация развивается уже в течение приблизительно 50 лет, но только сейчас достаточное внимание уделяется виртуализации ввода/вывода. Коммерческие процессоры, поддерживающие виртуализацию, появились только пять лет назад. Так что, в сущности, мы находимся на пороге перехода к платформенной виртуализации и виртуализации ввода/вывода. И, как один из ключевых элементов архитектур вычислительных систем будущего, таких как облачные вычисления, виртуализация, безусловно, будет рассматриваться как интересная технология, которая будет развиваться. Как обычно, Linux находится на переднем крае поддержки этих новых архитектур и в последних версиях ядра (2.6.27 и выше) начинает появляться поддержка этих новых технологий виртуализации.
После успешного перехода на линукс software разработчиков, выгадал момент, когда работы немного, и тоже сменил основную ОС. Опасения вызывал некроссплатформенный софт для поддержки уже имеющихся проектов. Часть софта заработало через wine. Однако оказалось, что определённый софт работать под wine'ом отказывается. Решено было запускать софт на виртуальной машине QEMU+KVM. Софт стал запускаться, но работать в нём было довольно не удобно. Программные виртуальные видеокарты не отличаются производительностью, да и поддержка 3D графики очень скромная. Пришлось расчехлять бубен и искать выход.
Искать выход долго не пришлось, но идея бить в бубен прожектором оказалась весьма странной. На тему проброса видеокарт в виртуальную машину интернет изобилует инструкциями различных времён и под различное железо. Чего стоит огромная статья на сайте Arch Linux'а [ 0 ]. Приведу сокращенную версию инструкции по пробросу видеокарты.
Looking Glass
Хоть данная технология и использует OpenGL, после gl пробел не нужен. А вот почитать инструкцию [ 5 ] на сайте проекта нужно обязательно. Для гостевой ОС скачать приложение захвата экрана looking-glass-host.exe [ 6 ], скачать и установить Microsoft Visual C++ 2015 Redistributable [ 7 ], скачать драйвер для IVSHMEM устройства [ 8 ]. Для хоста ставим зависимости, скачиваем и собираем клиентское приложение.
Запускаем виртуальную машину с IVSHMEM устройством. Размер памяти в 32Mb выбран для разрешения 1920x1080.
Подключаемся через VNC, устанавливаем драйвер на IVSHMEM устройство, возможно на него будет поставлен стандартный драйвер, находится в «Системные устройства». Запускаем looking-glass-host.exe. На хосте запускаем ./LookingGlass-a12/client/build/looking-glass-client .
На этом у меня заработала система с NVidia GF210, а затем по этому же маршруту удалось запустить Intel HD530. С разрешением экрана была маленькая проблемка, для смены на редкое разрешение, например 2048х1152, пришлось использовать Custom Resolution Utility [ 9 ].
Ещё один нюанс, при добавлении приложения looking-glass-host.exe в автозагрузку, нужно настроить автоматический вход пользователя, по соображениям безопасности гостевая ОС не даёт захватывать экран входа в систему.
Если не ставить задачу, получение изображения на физическом видео выходе, то данного результата будет достаточно для получения рабочей виртуальной машины с физической видеокартой и отзывчивым управлением. Управление осуществляется из хоста в отдельном окне или на полном экране. Однако есть нюансы.
Производительность. Накладные ресурсы на виртуализацию и не самая расторопная гостевая ОС не дадут с комфортом работать на слабом и средне-слабом железе. Потребуется мощный процессор не меньше 6-8 ядер, хорошая видеокарта для гостевой ОС, 16ГБ+ оперативной памяти, минимум по 8ГБ на каждую ОС. И танцы с бубном, чтобы выжать максимум из железа.
Терпение. Если сразу не заработает, то сил и времени придётся потратить прилично. Искать, читать, пробовать. Опять искать, читать и снова пробовать. Оставлю ещё несколько ссылок, которые мне попадались, возможно там будет ещё какая-нибудь полезная информация. [ 10 ] [ 11 ] [ 12 ]
… или как из игрового ноутбука средствами виртуализации сохранить игровую систему!
Если Вы рассматриваете ноутбук/ПК не только как игровую станцию, а еще и как хост для виртуальных машин, но при этом иногда нужно поиграть/поработать с 3d, то это возможно!
Поддержка в гипервизоре сквозного доступа к устройствам
Благодаря новейшим процессорам с архитектурой, поддерживающей виртуализацию, в ряде гипервизоров и схем виртуализации был реализован механизм сквозного доступ к устройствам. Вы сможете найти поддержку механизма сквозного доступа к устройствам (с использованием VT-D или IOMMU) в Xen и KVM, а также в других гипервизорах. В большинстве случаев, гостевая операционная система (домен 0) должны быть откомпилирована с использованием поддержки сквозного подхода, что реализовано как возможность, подключаемая во время создания ядра. Может также потребоваться механизм изоляции устройств от хостовой виртуальной машины (так, как это делается в Xen с помощью pciback). Есть некоторые ограничения, касающиеся PCI (например, устройства PCI, находящиеся за мостом PCIe-to-PCI, должны назначаться одному и тому же домену), но это ограничение не относится к PCIe.
Кроме того, механизм сквозного доступа к устройствам реализован в библиотеке libvirt (вместе с virsh), в которой предлагается абстракция конфигурационных схем, используемых в гипервизорах.
5. Настройки ВМ QEMU-KVM via virt-manager
Предварительно скачиваем iso-образ Windows 10 и драйвера Virtio от RedHat (тоже в виде iso-образа).
При первоначальной установке всегда ставим галочку « Customize configuration before install ».
1) Указываем iso-образ устанавливаемой операционной системы (например, Windows 10). Также добавляем дополнительное устройство вида «CD-ROM» и монтируем в доп. устройство iso-образ с драйверами Virtio.
2) Для виртуального HDD (куда планируется установка ОС) выставляем: « Bus type = Virtio ». Тип виртуального диска — qcow2 или raw.
3) Для более эффективной работы размещаем основной виртуальный диск для ВМ на SSD.
4) Модель сетевой карты - virtio.
5) Overview: chipset = “Q35”, firmware = “UEFI x86_64: /usr/share/OVMF/OVMF_CODE.secboot.fd”.
6) OS Information: Operation System = “Microsoft Windows 10”.
7) CPU (соответствующие блоки в XML должны выглядеть именно так, если речь про аналогичную аппаратную конфигурацию):
У меня есть новый гипервизор ESXi 7.0 U2 на сервере HP ProLiant DL360 Gen9. Внутри сервера есть USB контроллер. Задача — пробросить USB контроллер с хоста на виртуальную машину.
Переводим гипервизор в режим обслуживания, Maintenance Mode.
В vCenter 7 кликаем на наш гипервизор. Configure > PCI Devices.
Пока нет устройств в списке Passthrough-enabled. Нажимаем CONFIGURE PASSTHROUGH.
Находим в списке нужное нам устройство и выделяем галкой. Я нахожу ASMedia ASM1142 USB 3.1 Host Controller. OK.
В списке Passthrough-enabled появляется PCI устройство. Может потребоваться перезагрузка хоста.
Прокинем PCI устройство на виртуальную машину. Выбираем виртуалку, нажимаем Edit Settings. И добавляем новое устройство PCI Device. ADD NEW DEVICE > PCI Device.
Если у нас только один контроллер, то в списке от подставляется автоматически. Оставляем по умолчанию DirectPath IO. Читаем предупреждение о том, что на виртуалке с прокинутым PCI устройством нельзя делать некоторые вещи. Насколько я помню, нельзя ставить виртуалку на паузу, мигрировать на другой хост, использовать снапшоты. По идее виртуальная машина должна ещё зарезервировать оперативную память, раньше это нужно было делать вручную. OK.
Установка ProxMox и настройка хоста
Настоящая настройка софта, нюансы и описание метода будет происходить на примере моего ноутбука от Clevo N957TC (aka Hasee ZX7-ct5da), о котором я уже писал на Хабрахабре статью. Такого рода ноутбуки сейчас продают в России под брендом Dream Machines
Intel Core i7-8700, GTX 1660Ti, 16 Гб ОЗУ, 500Гб SSD, 15,6 дюйма
0-й этап. Проверяем что бы в BIOS'е были включены нужные параметры виртуализации, указанные в требованиях к железу выше в этой статьи.
В случае если нет второго ПК, то перед дальнейшей настройкой необходимо установить графический интерфейс для Linux. Для этого в консоли прописываете поочередно команды обновления репозитория:
после чего ставим выбранный GUI Linux (xfce4, gnome, kde, . ) на выбор, только ставить нужно полное окружение, иначе может не завестись сеть через браузер
либо, настроить возможность логина в графическое окружение пользователю root, чего я не рекомендую делать, но вдруг!?
После перезагрузки логинимся под тем юзером, кто нам ближе, открываем браузер, вводим в строке адреса сайта адрес WEB-интерфейса ProxMox (см. чуть выше по тексту), прописываем логин и пароль пользователя root и попадаем в меню настроек хоста гипервизора.
2-й этап. Настраиваем хост. Открываем консоль хоста под root'ом. Для этого в браузере выбираем слева название Вашего ProxMox сервера, данное Вами при установке, и кликнув на нем правой кнопкой мыши, выбираем меню Shell. В новом окне будем проделывать все настройки, либо можно запустить из графического окружения терминал и прописывать команды добавляя sudo:
GRUB_CMDLINE_LINUX_DEFAULT=«quiet intel_iommu=on iommu=pt pcie_acs_override=downstream,multifunction nofb nomodeset»
Если у Вас Процессор от AMD, то в строке выше intel_iommu=on меняете на amd_iommu=on . В сети есть свидетельства, что некоторым помогают дополнительные параметры в конце этой строки как video=vesafb:off,efifb:off , но при этом параметре после загрузки экран ноутбука погаснет.
После этой манипуляции необходимо сохранить файл и дать команду, с последующей перезагрузкой хоста:
Здесь последние три команды отвечают за частичное решение проблем с ошибкой 43, помогает на ряде оборудования, широко известной в узких кругах. А первые две за уменьшение проблем с работой пробрасываемого железа в виртуальную машину.
Сохраняем файл и выходим. Затем запрещаем ProxMox'у использовать следующие драйвера видеокарт на хосте:
Прописываем следующую команду (здесь 01:00 блок адресов дискретной ВК)
01:00.0 0300: 10de:2191 (rev a1)
01:00.1 0403: 10de:1aeb (rev a1)
01:00.2 0c03: 10de:1aec (rev a1)
01:00.3 0c80: 10de:1aed (rev a1)
На этом настройка самого ProxMox у нас закончена, необходимо дать следующие команды
и перезагрузить хост. Теперь у нас все готово к тому, что бы приступить к настройке виртуальных машин.
args: -cpu 'host,+kvm_pv_unhalt,+kvm_pv_eoi,hv_vendor_id=NV43FIX,kvm=off'
…
bios: ovmf
…
cpu: host,hidden=1,flags=+pcid
…
machine: pc-q35-3.1
…
hostpci0: 01:00.0,pcie=1,x-vga=on
args: -cpu 'host,+kvm_pv_unhalt,+kvm_pv_eoi,hv_vendor_id=NV43FIX,kvm=off'
bios: ovmf
boot: order=ide2;sata0;net0
cores: 4
cpu: host,hidden=1,flags=+pcid
efidisk0: local-lvm:vm-100-disk-0,size=4M
hostpci0: 01:00.0,pcie=1,x-vga=on
ide2: none,media=cdrom
machine: pc-q35-3.1
memory: 8196
name: Windows10
net0: virtio=BE:AB:28:39:99:70,bridge=vmbr0,firewall=1
numa: 0
ostype: win10
sata0: local-lvm:vm-100-disk-1,size=100G
scsihw: virtio-scsi-pci
smbios1: uuid=669a38fe-c0f1-481a-aae4-f2444fc2625f
sockets: 1
usb0: host=1-3,usb3=1
vga: none
vmgenid: f2576d2f-629e-4b4e-b9eb-59735c6e3050
Здесь нужно сказать следующее: несмотря на то что в виртуальную машину можно добавить программный видео-адаптер, я бы не рекомендовал это делать, т.к. сейчас важно определить работоспособность видеовывода. Если Ваше железо приняло все текущие настройки на ура, то при старте виртуальной машины с подключенным в правильный порт монитором вы увидите картинку с логотипом ProxMox на заставке. Дальше следуют 3 пути развития событий:
- Идеальный — весь процесс установки ОС вы будете наблюдать на внешнем мониторе. Тогда тормозим систему, пробрасываем USB мышь и временно USB клавиатуру. После чего вновь стартуем виртуальную машину и проводим установку до конца.
- Дальше логотипа ProxMox ситуация не сдвинется с места, не смотря на то, что если все-таки подключить софтовую видеокарту и подключится к виртуальной машине через видео-консоль, то процессом установки ОС можно будет управлять дальше. Здесь нужно остановиться и воспользоваться поиском, связанным с дополнительными параметрами в настройках файла grub или самого ProxMox. Т.к. если видеосигнал пошел. то и проброс возможен. Здесь нужно понять и определится в чем именно ошибка или нехватка каких-либо параметров.
- Черный дисплей и отсутствие видеосигнала на внешнем мониторе. Скорее всего вы потерпели фиаско и, если проблема не в отсутствии контакта, забытом переключателе питания или канале видео вывода на мониторе, то — увы!
ЗЫ. Т.к. настройка ноутбука окончательно не завершена, то статья будет дополнятся, в частности будут решаться проблемы о пробросе интегрированной видеокарты в виртуальную машину, пробросе клавиатуры ноутбука, тесты и сравнение нативного железа с виртуальным, а так же в планах снять видеоинструкцию о настройке системы.
Две разные системы (win + linux) на одной аппаратной базе - реальность. В этом нет ничего нового или инновационного (на данный момент времени), но если требуется максимальная производительность гостевой системы, то не обойтись без проброса реальных устройств в виртуальную машину. Проброс сетевых карт, usb-контроллеров (etc) экстраординарных особенностей не несёт, а вот попытка "шаринга" ресурсов видеокарты и процессора вполне может принести некоторое количество проблем.
Итак, а для чего, собственного говоря, городить системы с полнофункциональным использованием ресурсов GPU и CPU? Самый простой и очевидный ответ - игры (широко известный факт - если не большинство, то очень многие, написаны под ОС Windows). Другой вариант - полноценное рабочее место с возможностью запуска требовательных приложений (например, CAD-софта), быстрым бэкапом (скопировать файл ВМ куда проще, чем создавать полную копию HDD/SSD) и опцией полного контроля сетевого трафика гостевой системы.
5. Пробрасываем видеокарту в гостевую ОС
Для начала загрузимся с двумя видеокартами. Смотрим, что проброшенная карта появилась в системе, ставим на неё драйвера и убеждаемся, что они заработали.
После как проброшенная видеокарта заработала, и в диспетчере устройств пишет «Устройство работает нормально», запускаем виртуальную машину только с проброшенной видеокартой.
Подключаем к ней монитор и любуемся изображением рабочего стола гостевой ОС.
И тут начинается, самое интересное. У кого-то, всё хорошо, картинка пошла и дальше всё просто. Мой опыт два раза споткнулся на стадии отсутствия изображения. Первый раз был проброс встроенной видеокарты процессора Intel 6700T HD 530, видеовыходы были пустые и неудача была списана на то, что встройки плохо прокидываются. Второй раз же пробрасывалась внешняя Nvidia GF210, которая уже была специально куплена для экспериментов. Результат был ещё более интересен. В non EFI режиме видеокарта успешно пробрасывалась и даже показывала картинку, но выключение гостевой ОС давало осечку .
Последующий проброс мог просто повесить хост. Пара часов лёгкого гугления приводит к тому, что проблема зависания видеокарты довольно распространённая. К этому ведёт как некорректное завершение работы виртуальной машины, так и с некоторым шансом даже корректное выключение. Как выход рекомендуют пробрасывать в EFI режиме. Но VBIOS Nvidia GF210 не поддерживает EFI…
Шить или не шить, вот в чем вопрос
Не шить. QEMU поддерживает подмену VBIOS при пробросе видеокарты. Но VBIOS ещё придётся научить поддерживать EFI режим. Обычно это рекомендуют проверять перед тем как начать проброс видеокарты, например здесь [ 2 ]. Но дело приходится иметь с тем, что есть, и искать свежую видеокарту с поддержкой EFI не хотелось. Значит нужно патчить VBIOS. Все операции выполняемые с VBIOS, делаются на свой страх и риск. Мной использовалось комплект ПО и инструкция к нему от сюда [ 3 ]. После считывания VBIOS получаем файл gt210.rom , патчим и на выходе имеем gt210_uefi.rom . Вот его и нужно подсунуть видеокарте при загрузке виртуальной машины.
Запускаем виртуальную машину и смотрим.
Дальнейшее развитие виртуализации ввода/вывода
Уже сегодня виртуализация ввода/вывода развивается дальше. Например, шина PCIe поддерживает виртуализацию. Одна их концепций, которая идеальна для виртуализации серверов, называется Single-Root I/O Virtualization (SR-IOV). Эта технология виртуализации (созданная группой PCI-Special Interest Group, или PCI-SIG) обеспечивает виртуализацию устройств в сложных системах с одной корневой системой (случай, когда устройство используется на одном сервере с несколькими виртуальными машинами). Еще один вариант, называемый Multi-Root IOV, поддерживает более сложные варианты топологии (такие как блейд-сервера, где несколько серверов могут получить доступ к одному или нескольким устройствам PCIe). В некотором смысле, это позволяет использовать сколь угодно большие сети устройств, включающие в себя серверы, конечные устройства, и коммутаторы (со средствами идентификации устройств и средствами пакетной маршрутизации).
В рамках концепции SR-IOV устройство PCIe может экспортировать не только ряд физических функций шины PCI, но также ряд виртуальных функций, которые совместно используют ресурсы на устройстве ввода/вывода. Упрощенная архитектура сервреной виртуализации приведена на рис.4. В этой модели сквозной доступ к устройству не нужен, так как виртуализация осуществляется для конечного устройства, поэтому гипервизору для того, чтобы достичь производительности, равной производительности аппаратного обеспечения и обеспечить безопасность за счет изоляции, достаточно просто отобразить виртуальные функции в виртуальные машины.
Рис.4. Сквозной доступ с использованием SR-IOV
Что нам потребуется для установки и настройки
ПКНоутбук с дискретной игровой видеокартой у которого схема подключения к дисплею/монитору типа MUXed- Роутер с доступом в интернет (Для настройки и последующего использования я бы рекомендовал подключаться кабелем к роутеру)
- Физически выделенный жесткий диск SSD под хост и виртуальные машины объёмом от 250Гб
- Загрузочная USB флешка с ProxMox'ом (надстройка над Debian Linux + KVM)
- Последняя версия VirtIO драйверов
- Дополнительный внешний монитор, подключённый к Вашему ноутбуку кабелем в видео-разъем управляемым напрямую дискретной видеокартой (кроме случаев, если у Вас дисплей ноутбука напрямую подключен к дискретной видеокарте)
- Дополнительную мышь и клавиатуру для гостевой системы, по крайней мере для первоначальной настройки
- Для удобства — второй ПК/ноутбук в сети на время установки и настройки софта, категорически для Вашего удобства, но это не является необходимым условием работы и дальнейшей эксплуатации такого ноутбука.
Платформенная эмуляция устройств
Прежде, чем перейти к технологии сквозного доступа, давайте рассмотрим, как эмуляция устройств используется в настоящее время в двух различных вариантах архитектуры гипервизоров. В первом варианте эмуляция устройств осуществляется в самом гипервизоре, тогда как во втором варианте эмуляция устройств переносится в отдельное приложение, внешнее по отношению к гипервизору.
Эмуляция устройства внутри гипервизора является обычным приемом, реализованным, например, в приложении VMware workstation (гипервизор на базе операционной системы). В этой модели внутри гипервизора реализована эмуляция обычных устройств, которые одновременно используются различными гостевыми операционными системами, это - виртуальные диски, виртуальные сетевые адаптеры и другие важные платформенные компоненты. Эта модель изображена на рис.1.
Рис.1. Эмуляция устройства внутри гипервизора
Второй вариант архитектуры называется эмуляцией устройств в пользовательском пространстве (см. рис.2). Как следует из названия, эмуляция устройств происходит не в гипервизоре, а в пользовательском пространстве. Например, приложение QEMU (в котором реализована не только эмуляция устройств, но также есть и гипервизор) само выполняет эмуляцию и используется большим количеством независимо реализованных гипервизоров (только два из них — виртуальная машина на базе ядра Linux KVM и VirtualBox). В этой модели преимущество в том, что эмуляция устройств независима от гипервизора и эти устройства могут одновременно использоваться несколькими гипервизорами. При таком подходе возможна эмуляция любых устройств, причем это не ляжет дополнительной нагрузкой на гипервизор (который оперирует в привилегированном режиме).
Рис.2. Эмуляция устройств в пользовательском пространстве
Перенос эмуляции устройств из гипервизора в пользовательское пространство дает некоторые очевидные преимущества. Наиболее важное касается базиса, обеспечивающего безопасную работу вычислительной системы TCB (trusted computing base). К TCB системы относятся все компоненты, которые критичны с точки зрения обеспечения безопасной работы системы. Разумеется, что если размер системы меньше, то меньше вероятность ошибок системы и система, следовательно, будет более безопасной. То же самое относится к гипервизору. Безопасность работы гипервизора имеет решающее значение, поскольку он изолирует несколько независимо работающих гостевых операционных систем. Чем меньше кода в гипервизоре (за счет переноса эмуляции устройств в менее привилегированное пользовательское пространство), тем меньше вероятность несанкционированного получения привилегий сторонними пользователями.
Еще одним вариантом эмуляции устройств с использованием гипервизора является использование драйверов паравиртуализации. В этой модели в состав гипервизора входят драйвера для работы с физически существующими устройствами, а в каждой гостевой операционной системе имеется специальный драйвер, который работает во взаимодействии с драйверами гипервизора (называемыми паравиртуализированными драйверами или PV драйверами).
Независимо от того, выполняется ли эмуляция устройства в гипервизоре или выше - в гостевой виртуальной машине (VM), методы эмуляции аналогичны. При эмуляции устройств могут имитироваться конкретные устройства (например, сетевой адаптер Novell NE1000), либо конкретный тип диска (например, диски Integrated Device Electronics - IDE). Физическое оборудование может существенно различаться, например, когда в гостевых операционных системах эмулируется диск IDE, в физической аппаратной платформе может использоваться диск Serial ATA (SATA). Это удобно, поскольку поддержка дисков IDE есть во многих операционных системах и это можно использовать в роли общего подхода вместо того, чтобы во каждой гостевой операционной системе осуществлять поддержку дисков более современного типа.
Заглянем "под капот" технологии эмуляции устройств
В ранних вариантах эмуляции устройств в гипервизоре создавался специальный вид интерфейса устройства, который в гостевой операционной системе реализовывал виртуальный интерфейс к аппаратному обеспечению. Этот виртуальный интерфейс должен был представлять собой общепринятый интерфейс устройства, в состав которого входят виртуальное адресное пространство для конкретного устройства (например, виртуальная шина PCI) и виртуальные прерывания. Но с драйвером устройства взаимодействует виртуальный интерфейс, а гипервизор транслирует это взаимодействие в фактически существующее оборудование, в результате возникали большие накладные расходы, особенно в случае использования устройств с высокой пропускной способностью, таких как сетевые адаптеры.
В Xen пропагандировался подход с использованием паравиртуализации (рассмотренный в предыдущем разделе), который уменьшал потерю производительности за счет того, что драйвер гостевой операционной системы имел информацию о том, что он виртуальный. В этом случае гостевая операционная система не обращалась к адресному пространству на шине PCI, выделенному для устройства (например, сетевого адаптера), а вместо этого использовала интерфейс прикладного программного обеспечения для этого сетевого адаптера (API), что позволяло использовать более высокий уровень абстракции (например, пакетный интерфейс). Недостаток этого подхода в том, что для использования паравиртуализации гостевую операционную систему нужно было модифицировать. Преимущество было в том, что в некоторых случаях вы могли достичь производительности, почти равной производительности аппаратного обеспечения.
В первых вариантах, реализующих сквозной доступ к устройствам, была предложена простая модель эмуляции, в которой гипервизор программным образом осуществлял управление памятью (трансляцию адресного пространства гостевой операционной системы в адресное пространство доверенного хоста). И хотя в первых реализациях были предоставлены средства, позволяющие изолировать использование устройства только конкретной гостевой операционной системой, у этого подхода не хватало производительности и масштабируемости, необходимой для больших виртуальных сред. К счастью, у поставщиков процессоров появились процессоры нового поколения, имеющие инструкции для поддержки гипервизоров, а также логики сквозного доступа к устройствам, в том числе виртуализации прерываний и поддержка прямого доступа к памяти (DMA). Таким образом, вместо того, чтобы отлавливать и эмулировать доступ к физическим устройствам, лежащим ниже гипервизора, в новых процессорах для эффективного сквозного доступа к устройствам поддерживается трансляция адресов DMA и проверка прав доступа.
2. Аппаратная часть
Процессор: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz
Материнская плата: ASRock Z390 Phantom Gaming 4S
Видеокарта 0 (для проброса в ВМ): Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]
Видеокарта 1 (для хост-системы): Park [Mobility Radeon HD 5430]
USB-контроллер (для проброса в ВМ и последующего подключения периферийных устройств, например, клавиатуры): VIA Technologies, Inc. VL805 USB 3.0 Host Controller
Введение
Настоящая статья задумана как инструкция и развитие моей предыдущей статьи (Как из домашнего ПК средствами виртуализации сохранить игровую систему) по настройке хоста под виртуализацию с пробросом видеокарты игровой серий, не профессиональной. О пробросе интегрированной видеокарты будет сказано в конце статьи отдельно.
1. Включаем поддержку IOMMU в ядре.
GRUB_CMDLINE_LINUX_DEFAULT=«quiet splash amd_iommu=on»
или
GRUB_CMDLINE_LINUX_DEFAULT=«quiet splash intel_iommu=on»
Не забываем sudo update-grub .
Темнота
Выходы видеокарты сияли темнотой. В очередной раз мораль проходила испытание неудачей. Первое, что приходит в голову, гостевая ОС падает при старте. Логи, мне нужны её логи. Для этого запускаем vga_qxl.sh . Смотрим предыдущий запуск. А там всё хорошо, кроме того, что питание резко дёрнули. Получается, что оно работает, хотя и не работает. Первая идея была подключиться по RDP и посмотреть, что же там происходит, но всё же лучше для этого использовать VNC, например tightvnc [ 4 ]. Устанавливаем VNC, настраиваем на 5600 порт и прокидываем этот порт для доступа из хоста.
Подключаемся и видим рабочую машину, только монитор у неё странный Generic Non-PnP Monitor (Универсальный монитор не PnP). Картинка есть, значит можно пробовать запускать Looking Glass.
Аппаратная поддержка сквозного доступа к устройствам
Как Intel, так и AMD обеспечивают поддержку сквозного доступа к устройствам в своих процессорах с новой архитектурой (в дополнение к новым инструкциям, которые поддерживают работу гипервизора). Intel использует свой вариант, называемый Virtualization Technology for Directed I/O (VT-d), в то время как AMD использует вариант I/O Memory Management Unit (IOMMU). В каждом случае, новые процессоры предоставляют средства отображения физических адресов шины PCI в виртуальные адреса гостевых систем. Когда выполняется это отображение, доступ (и защита) реализуются на уровне аппаратного обеспечения и гостевая операционная система может использовать устройство, как если бы система не была виртуальной. В дополнение к отображению гостевой системы в физическую память, поддерживается изоляция устройства таким образом, чтобы другие гостевые системы (или гипервизор) не имели к нему доступа. В процессорах Intel и AMD реализована поддержка еще многих функций, предназначенных для виртуализации. Подробности вы можете узнать из статей, перечисленных в разделе "Ресурсы" оригинала статьи.
4. Установка софта для виртуализации
1) « dnf install epel-release ».
2) « dnf install qemu-kvm qemu-img libvirt virt-install libvirt-client virt-viewer virt-manager seabios numactl perf cockpit cockpit-machines xauth virt-top libguestfs-tools ».
3) « dnf install @virt ».
4) Optional. « dnf install perl » (Perl – one love).
Ограничения метода
Для проброса именно дискретной видеокарты ноутбука/PCI-Express порт с установленной видеокартой необходимо выполнение следующих условий:
Здесь нас из первого линстинга интересует адрес видеокарты и сопутствующих устройств, видно, что помимо видеокарты в одном блоке идет аудио-контроллер, а так же USB type-C контроллер, а в следующем листинге мы видим что устройства входят сообща в одну и ту же IOMMU-группу и при пробросе физически другим устройствам мешать не будут, следовательно проброс в теории возможен! Дальше только практика.
3. Настройки ОС
В качестве хост-системы выбрана ОС AlmaLinux 8 (вариант установки«Server with GUI»). Долгое время пользовался CentOS 7/8, поэтому, думаю, выбор тут очевиден.
Первое, что необходимо сделать, - это ограничить использование видеокарты, предназначенной для использования в ВМ, хост-системой. Для этого применяем ряд команд и настроек:
1) с помощью команды « lspci -nn | grep RX » получаем уникальные идентификаторы видеокарты. Т. к. видеокарта RX-серии, то, соответственно, ищем в выводе lspci (утилита устанавливается посредством команды « dnf install pciutils ») по этим двум символам. Вывод получим примерно такой (выделенные подстроки — это и есть искомые идентификаторы устройств) -
«02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] [1002:699f] (rev c7)
02:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] [1002:aae0] », где 1002:699f — идентификатор VGA-контроллера, а 1002:aae0 — встроенной аудиокарты. Также запоминаем идентификаторы «02:00.0» и «02:00.1»;
2) добавив к команде « lspci -nn » ключ « k » (« lspci -nnk ») находим в выводе устройство «1002:699f» и запоминаем значение «Kernel driver in use» . В моём случае — это « amdgpu »;
3) в файле « /etc/default/grub » находим строку, начинающуюся с « GRUB_CMDLINE_LINUX », и добавляем после « quiet » значения «intel_iommu=on iommu=on rd.driver.pre=pci-stub pci-stub.ids=1002:67ff,1002:aae0», где « intel_iommu / iommu » – параметры, отвечающие за поддержку технологии IOMMU (технология взаимодействия виртуальных машин с реальным оборудованием), «rd.driver.pre=pci-stub» - указание на принудительную первоочередную загрузку фиктивного драйвера pci-sub, «pci-stub.ids» - перечисление устройств, для которых при загрузке ядра необходимо использовать фиктивный драйвер (т.е. происходит изоляция устройств для дальнейшего использования в виртуальных машинах). Если на хост-машине используется CPU от AMD, то «intel_iommu» меняем на «amd_iommu»;
4) в файл « /etc/modprobe.d/local.conf » добавляем строки « blacklist amdgpu » и « options pci-stub ids=1002:67ff,1002:aae0 », где « blacklist amdgpu » - явное указание на запрет использования драйвера AMD для графических устройств, а « options pci-stub ids=1002:67ff,1002:aae0 » - явное указание на использование фиктивного драйвера для соответствующих идентификаторов устройств;
5) выполняем команду « grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg » (т.е. пересоздаём конфигурационный файл загрузчика GRUB). Если речь не про EFI-загрузку, то команда выглядит так - « grub2-mkconfig -o /boot/grub2/grub.cfg »;
6) выполняем команду « dracut --regenerate-all --force » для пересоздания образа initramfs (initial RAM disk image, загружаемый в оперативную память файл с образом файловой системы), используемого при загрузке Linux в качестве первоначальной корневой файловой системы;
7) перезагружаем хост виртуализации.
Смысл этих настроек в том, чтобы ограничить использование определённых устройств при загрузке. Например, до прописания параметров в выводе команды «lspci -v» для VGA-контроллера будет присутствовать подстрока « Kernel driver in use: amdgpu », а после перезагрузки – « Kernel driver in use: pci-stub ». При старте же ВМ с Windows (и после проброса устройств) – “ Kernel driver in use: vfio-pci ” (в чём можно убедиться после запуска созданной ВМ). Важный момент — используемая для хост-системы видеокарта должна использовать драйвера, отличные от используемых для пробрасываемой видеокарты, например, в моём случае используется «Radeon HD 5430», драйвер для которой — это «radeon» (в выводе « lspci -v » – « Kernel driver in use: radeon »).
Проблемы со сквозным доступом к устройствам
Одна из проблем, связанная со сквозным с доступом к устройствам, возникает, когда требуется "живая миграция". "Живой миграцией" (Live migration) является приостановка виртуальной машины с последующим его переносом на новый физический хост, на котором виртуальная машина перезапускается. Это отличная возможность для поддержки балансировки нагрузки, связанной с виртуальными машинами, в сети из физических хостов, но возникает проблема, если используется сквозной доступ к устройствам. Горячее подключение к шине PCI (для которого есть несколько спецификаций) является одним из аспектов, которые нужно решить. При горячем подключении к шине PCI должна быть возможность добавлять устройства PCI к ядру и удалять их из ядра, что было бы идеальным, особенно когда миграция виртуальной машины осуществляется на гипервизор на новой хостовой машине (устройства должны быть отсоединены, а затем подключены к новому гипервизору) . Когда эмулируются устройства, такие как виртуальные сетевые адаптеры, то создается специальный слой, абстрагированный от физического оборудования. В этом случае виртуальный сетевой адаптер легко мигрирует в пределах виртуальной машины (поддерживается привязка к драйверам Linux и допускается привязка нескольких драйверов к одному и тому же интерфейсу).
4. Настраиваем QEMU и запускаем гостевую ОС
Запускаем виртуальную машину без проброса видеокарты для установки гостевой ОС. Так как стоит прицел на Looking Glass, то для гостевой стоит выбирать Windows 10. Windows 8/8.1 по последнем данным тоже поддерживаются.
3. Перезагружаемся и проверяем, что всё получилось
DMAR: Intel® Virtualization Technology for Directed I/O
или
AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
AMD-Vi: Interrupt remapping enabled
AMD-Vi: Lazy IO/TLB flushing enabled
Составные устройства попали в одну группу.
/sys/kernel/iommu_groups/15/devices/0000:01:00.0
/sys/kernel/iommu_groups/15/devices/0000:01:00.1
/sys/kernel/iommu_groups/16/devices/0000:02:00.0
/sys/kernel/iommu_groups/17/devices/0000:03:00.0
/sys/kernel/iommu_groups/18/devices/0000:04:00.0
/sys/kernel/iommu_groups/18/devices/0000:04:00.1
Драйвера KVM и VFIO загружены.
Видеокарта для гостевой ОС захвачена VFIO.
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2)
Kernel driver in use: vfio-pci
Kernel modules: nvidiafb, nouveau
04:00.1 Audio device [0403]: NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1)
Kernel driver in use: vfio-pci
Kernel modules: snd_hda_intel
Читайте также: