Глава 6. Устройства и протоколы Виртуальных устройств отображения

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

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

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

Некоторым новым ОС, запускаемым в виртуализации KVM не следует применять более старые адаптеры графических карт по целому ряду причин. Например, начиная с Red Hat Enterprise Linux/ CentOS 7, рекомендуется не применять для Windows 10 b Windows Server 2016 виртуальную видеокарту cirrus. Основная причина для этого связана с имеющейся нестабильностью получаемой виртуальной машины, а также с тем фактом, что - скажем - вы не сможете применять разрешающую способность отображения Full HD с виртуальной видеокартой cirrus. На всякий случай, если вы приступаете к установке этих гостевых ОС убедитесь то вы пользуетесь ведеокартой QXL, ибо она обеспечивает наилучшую производительность и совместимость с протоколом удалённого отображения SPICE.

Теоретически, вы всё ещё можете применять виртуальные графические карты cirrus для некоторых действительно старых гостевых ОС (старее Windows NT такой как 4.0 и старых клиентов гостевых ОС, таких как Windows XP), но это всё. Для всего прочего намного лучше применять либо драйвер std, либо драйвер QXL, поскольку они предлагают наилучшие поддерживаемые производительность и ускорение. Более того, эти виртуальные графические карты также предлагают более высокие разрешающие способности отображения.

Существуют и некоторые прочие доступные виртуальные видеокарты для QEMU, такие как встроенные драйверы для различных устройств SoC (System on a Chip), ati vga, bochs и ому подобных. Некоторые из них применяются часто, например, SoC - просто вспомните все эти имеющиеся в мире Raspberry Pi и BBC Micro:bit. Эти новые варианты виртуальной графики дополнительно расширяются IoT (Internet of Tings). Итак, имеется множество веских причин, по которым нам необходимо уделять пристальное внимание тому, что происходит на данном рынке.

Давайте покажем это на неком примере. Скажем, мы желаем создать некую новую виртуальную машину, которая намерена обладать установленным в ней неким набором индивидуальных параметров в терминах того как мы будем осуществлять доступ к ей виртуальному дисплею. Если вы помните, в Главе 3, Установка гипервизора KVM, libvirt и oVirt мы обсуждали различные команды управления libvirt (virsh? virt-install) и мы также создавали некоторые виртуальные машины при помощи virt-install и некие персональные параметры. Давайте присоединимся к этому и воспользуемся аналогичным примером:

virt-install --virt-type=kvm --name MasteringKVM01 --vcpus 2 --ram 4096 --os-variant=rhel8.0 --/iso/CentOS-8-x86_64-1905-dvd1.iso --network=default --video=vga --graphics vnc,password=Packt123 --disk size=16
 	   

Вот что должно произойти:

После того как мы наберём значение пароля (Packt123, как это предписано в параметре настроек virt-install) нам предстанет такой экран:

Как уже говорилось, мы просто воспользовались этим как примером того, как добавлять расширенный вариант в команду virt-install, в частности, как установить виртуальную машину с определ1нной видеокартой.

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

Как мы уже обсуждали в Главе 1, Основы виртуализации KVM, VDI это понятие, которое использует парадигму виртуализации для ОС клиентов. Это означает, что конечные пользователи подключаются напрямую к своим виртуальным машинам запуская некую ОС клиента (скажем, Windows 8.1, Windows 10 или Linux Mint), которая либо зарезервирована для них, либо объединена в пул, что означает, что множество пользователей могут выполнять доступ к одним и тем же виртуальным машинам и получать доступ к своим данным через дополнительные возможности VDI.

Теперь, если мы говорим о большинстве бизнес- пользователей, им требуется нечто, что мы в шутку называем пишущей машинкой. Эта модель применения относится к сценарию, при котором пользователь пользуется клиентской ОС для чтения документов и их написания, электронной почты и просмотра Интернета. И для таких вариантов применения когда мы применяем какое- то решение на основе производителя (решения Horizon VMware, Xen Desktop Citrix или основанные на Remote Desktop службы VDI Microsof), мы были бы способны делать это с любым из них.

Однако тут имеется одно большое но. Что произойдёт когда такой сценарий содержит сотни пользователей, которым требуется доступ к 2D и/ или 3D видео ускорению? Что происходит когда мы разрабатываем некое VDI решение создающих проекты компаний - архитектурных, трубопроводных, нефтегазовых или производящих видео? Запуск решений VDI на основе ЦПУ и программно- определяемых виртуальных видеокарт не даст нам ничего, особенно при масштабировании. Именно здесь более функционально насыщенными будут Xen Desktop и Horizon, если мы говорим об уровне технологий. И, честно говоря, методы на основе KVM не так уж сильно отстают с точки зрения параметров отображения, просто они несколько отстают от некоторых прочих функциональных возможностей корпоративного уровня, которые мы обсудим в последующих главах, например, в Главе 12, Горизонтальное масштабирование KVM посредством OpenStack.

В целом имеются три концепции, которые мы можем применять для получения производительности видеокарт для некой виртуальной машины:

Если воспользоваться в качестве некой метафоры Horizon VMware, эти решения будут именоваться построением изображений (рендерингом) в ЦПУ, vDGA (Virtual Direct Graphics Acceleration ) и vSGA (Virtual Shared Graphics Acceleration). Или, в Citrix, мы бы говорили об HDX 3D Pro. В CentOS мы говорим об устройствах посредниках (mediated devices) в сценарии совместно используемых видеокарт.

Когда мы говорим о пробросе (passthrough) PCI, он несомненно доставит наилучшую производительность, поскольку вы сможете применять видеокарту PCI- Express, причём напрямую в виртуальную машину, установить внутри своей гостевой ОС естественный драйвер и получить графическую карту целиком для своих нужд. Однако это создаёт четыре проблемы:

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

Следующая тема в нашем списке - как именно применять GPU более современным способом - применяя концепцию разбиения GPU для предоставления частей GPU множеству виртуальных машин. Давайте поясним как это работает и как настраивается на примере GPU nVidia.

 

Разбиение GPU на части на примере vGPU nVidia

Давайте воспользуемся примером чтобы посмотреть как мы можем применять тот сценарий, при котором мы разбиваем своё GPU на части (vGPU nVidia) для своих виртуальных машин на основе KVM. Эта процедура очень похожа на процедуру SR-IOV, которую мы обсуждали в Главе 4, Сетевая среда libvirt, в которой мы применяли в поддерживаемой Intel сетевой карте для представления виртуальных функций в нашем хосте CentOS, которые мы далее предоставляли в свои виртуальные машины предоставляя им восходящие соединения к установленному мосту KVM.

Прежде всего, нам требуется проверить какой вид видеокарты у нас имеется и она должна относиться к к поддерживаемым (в нашем случае мы пользуемся Tesla P4). Давайте воспользуемся командой lshw для проверки своих устройств отображения, что должно выглядеть аналогично следующему:

# yum -y install lshw
# lshw -C display
*-display
       description: 3D controller
       product: GP104GL [Tesla P4]
       vendor: NVIDIA Corporation
       physical id: 0
       bus info: pci@0000:01:00.0
       version: a0
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress cap_list
       configuration: driver=vfio-pci latency=0
       resources: irq:15 memory:f6000000-f6ffffff memory:e0000000-efffffff memory:f0000000-f1ffffff
		

Получаемый вывод этой команды сообщает нам что у нас имеется 3D- совместимое GPU - а именно, основанный на nVidia GP104GL продукт. Она сообщает нам что это устройство уже применяет драйвер vfio-pci. Этот драйвер является естественным драйвером SR-IOV для VF (Virtualized Functions, Виртуальных функций). Эти функции составляют ядро функциональности SR-IOV. Мы объясняем это использованием такой способности SR-IOV GPU.

Первое что нам надлежит предпринять - всё что все мы пользователи nVidia GPU применяли все эти годы - это установка в чёрный список установленного драйвера nouveau, который мешает нам. И, когда мы намерены применять разбиение на части GPU на постоянной основе, нам требуется превратить это в постоянное с тем, чтобы он не загружался при запуске нашего сервера. Однако будьте осторожны - порой это может приводить к неожиданному поведению, например, к запуску сервера без какой бы то ни было видимой причины. Итак, нам требуется создать файл настроек для modprobe, который будет заносит в чёрный список соответствующий драйвер nouveau. давайте создадим файл с названием nouveauoff.conf в каталоге /etc/modprobe.d со следующим содержимым:

blacklist nouveau
options nouveau modeset 0
 	   

Затем нам необходимо принудить наш сервер повторно создать необходимый нам образ initrd, который загружается при запуске нашего сервера и перезапускает этот сервер чтобы ввести в действие эти изменения. Мы намерены сделать это при помощи команды dracut, за которой следует обычная команда reboot:

# dracut –-regenerate-all –force
# systemctl reboot
		

После этого перезапуска давайте проверим что наш драйвер vfio для видеокарты nVidia загружен и, если это так, проверить службу диспетчера vGPU:

# lsmod | grep nvidia | grep vfio
nvidia_vgpu_vfio 45011 0
nvidia 14248203 10 nvidia_vgpu_vfio
mdev 22078 2 vfio_mdev,nvidia_vgpu_vfio
vfio 34373 3 vfio_mdev,nvidia_vgpu_vfio,vfio_iommu_type1
# systemctl status nvidia-vgpu-mgr
vidia-vgpu-mgr.service - NVIDIA vGPU Manager Daemon
   Loaded: loaded (/usr/lib/systemd/system/nvidia-vgpu-mgr.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2019-12-12 20:17:36 CET; 0h 3min ago
Main PID: 1327 (nvidia-vgpu-mgr)
		

Нам требуется создать некий UUID, который мы будем применять для представления своей виртуальной функции в виртуальную машину KVM. Для этого мы воспользуемся командой uuidgen:

# uuidgen
c7802054-3b97-4e18-86a7-3d68dff2594d
		

Теперь давайте воспользуемся этим UUID для той виртуальной машины, которая будет разделять наше GPU. Для этого нам требуется создать некий файл шаблона XML, который мы будем добавлять к уже имеющимся файлам XML для своих виртуальных машин через copy-paste. Давайте создадим этот vsga.xml:

<hostdev mode='subsystem' type='mdev' managed='no' model='vfio-pci'>
  <source>
    <address uuid='c7802054-3b97-4e18-86a7-3d68dff2594d'/>
  </source>
</hostdev>
 	   

Применяйте эти настройки в качестве шаблона и просто вставляйте копированием (copy-past) для наполнения содержимого файла XML любой виртуальной машины когда вы желаете получить доступ к нашему разделяемому GPU.

{Прим. пер.: материал этого раздела весьма устарел, хотя в целом и отражает направление работ. Сейчас nVidia лицензирует разбиение GPU на VF и для сопровождения этой функциональности требуется приобретать лицензии и устанавливать один или более серверов лицензий, без которых не поддерживается свойства виртуальных функций PCI GPU, в которых такая функциональность возможна. Эта процедура относительно гладко выполняется для VMware и Citrix Xen, однако документация nVidia очень слабо отражает процесс настройки данной функциональности в KVM Linux и RHEL (последний обладает рядом отличий). Если запутались, но всё же желаете выполнить эти настройки, обратитесь к нам. Оказываем консультации по установке в CentOS/ RHEL и Ubuntu. Также не согласимся с авторами, что этот процесс масштабируется для корпоративного уровня хуже VMware и Citrix. Подробнее в нашем переводе Практической автоматизации предприятия в Linux Джеймса Фримана, изданной в январе 2020.}

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

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

Наш следующим логичным шагом была бы установка драйвера nVidia для этой карты под Linux с тем чтобы свободно применять её в качестве своего дискретного GPU.

Теперь давайте перейдём к следующему важному объекту, который относится к протоколам удалённого отображения. Мы как бы уже крутились вокруг этой темы в своей предыдущей части этой главы, но теперь мы намерены заняться этим непосредственно.

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

Всегда будут иметься люди, оспаривающие данную предпосылку, но удалённые протоколы начинались как исключительно текстовые. Как ни крути, но терминалы последовательного текстового режима существовали здесь задолго до того как у нас появились X Windows или ещё что либо, отдалённо напоминающее графический интерфейс во вселенных на основе Microsoft, Apple и UNIX. Кроме того, также невозможно оспорить тот факт, что для доступа к удалённым дисплеям использовались протоколы telnet и rlogin. Так уж получилось, что удалённый дисплей, к которому мы обращаемся при помощи telnet и rlogin является текстовым дисплеем. В более широком смысле то же самое относится и к SSH. И последовательные терминалы, и текстовые консоли, а также основанные на тексте такие протоколы как telnet и rlogin выступали чем- то наиболее распространённым применяемым в качестве стартового момента, который уходит в далёкие 1970-е.

Окончание 1970х стало важным периодом в истории вычислительной техники, ибо предпринимались многочисленные попытки начать массовое производство персональных компьютеров для большого числа людей (к примеру, Apple II c 1977). В 1980м люди стали больше применять персональные компьютеры, на что укажет вам любой почитатель Amiga, Commodore, Atari, Spectrum или Amstrad. Зарубите себе на носу, что самые первые нстоящие общедоступные ОС на основе графического интерфейса на появлялись вплоть до Xerox Star (1981) и Apple Lisa (1983). Самой первой общедоступной ОС с графическим интерфейсом пользователя на основе Apple стала Mac OS System 1.0 в 1984. Большинство прочих упомянутых ранее компьютеров пользовались текстовыми ОС. Даже игры той эпохи выглядели так, быдто бы они рисовались вручную пока вы играли в них. Amiga's Workbench 1.0 была выпущена в 1985 и со своим графическим интерфейсом и моделью использования цветов она намного опередила своё время. Тем не менее, 1985й, скорее всего, запомнится ещё чем- то - именно в этом году была выпущена операционная система Microsof Windows OS (v1.0). Позднее она превратилась в Windows 2.0 (1987), Windows 3.0 (1990), Windows 3.1 (1992), которыми Microsoft уже штурмом завоевала мир ОС. Да имелись и ОС прочих производителей:

Всё это оказалось просто крошечной точкой на горизонте по сравнению с гигантским штормом, случившемся в 1995м, когда Microsoft представила Windows 96. Это была первая клиентская ОС Microsoft, которая была способна по умолчанию загружаться с графическим интерфейсом, поскольку предыдущие версии запускались из командной строки. Затем пришли Windows 98 и XP, что подразумевало ещё бо́льшую долю рынка для Microsoft. оставшаяся часть истории вам, скорее всего, хорошо знакома по Vista, Windows 7, Windows 8 и Windows 10.

Смысл этой истории не в том чтобы обучить вас историческим событиям как таковым. Речь идёт о том, чтобы отметить саму тенденцию, что достаточно просто. Мы начинали с текстовых интерфейсов в командной строке (скажем, в IBM и MS DOS, ранних версиях Windows, Linux, UNIX, Amiga, Atari и тому подобного). Затем мы постепенно перешли к большому числу визуальных интерфейсов (GUI). Благодаря достижениям в области новых сетевых технологий, графического процессора, центрального процессора и технологий мониторинга мы достигли некого этапа, на котором мы желаем сиятельного монитора с разрешением 4k при 4- мегапиксельной степени разрешающей способности, низкой латентностью, гигантской мощностью ЦПУ, фантастической цветопередачей и определёнными практиками пользователя. Такие практики пользователя должны быть незамедлительными и в действительности не важно применяем ли мы локальную ОС или же удалённую (VDI, облачное решение, или же иную лежащую в основе технологию).

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

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

Если мы и дальше расширим свой список до применяемых под VDI протоколов, то список окажется ещё длиннее: