Виртуальная видеокарта для игр: «Виртуальный ПК» и «Виртуальные приложения» – Новый сервис от NVIDIA – виртуальная видеокарта

Виртуальный сервер Windows с видеокартой на борту / VPS.house corporate blog / Habr

Виртуальный сервер уже давно перестал быть чем-то IT-шным и все чаще данной услугой интересуются люди с совершено различными и повседневными рабочими задачами: от размещения бухгалтерских программ до программ по автоматизации рутинных SEO-задач, от игровых серверов до самих игр (самых современных!), от общего файлового сервера небольшой организации до полноценных удалённых рабочих столов крупных компаний.

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

Возможность виртуализации ресурсов видеокарт не нова и присутствует во всех популярных средах: Hyper-V, KVM, XEN, VirtualBox и собственная среда от самого популярного производителя чипсетов – NVIDIA GRID.

В данной статье мы будем говорить о RemoteFX – возможностях видеокарт на виртуальных серверах под управлением Hyper-V, именно на этой платформе они работают на VPS.house с видеокартами профессионального уровня NVIDIA Quadro P6000.

В качестве простой демонстрации поведем тест, взяв конфигурацию VPS с 2 ядрами процессора и 2 ГБ оперативной памяти с виртуальной видеокартой 256МБ памяти и без. В обоих случаях мы откроем в браузере Internet Explorer пример на WebGL одной и той же страницы.

Результат на виртуальном сервере, где установлена видеокарта:

Если видеокарту с этого же сервера убрать:

Итак, с видеокартой мы получаем 42 кадра в секунду, без нее – всего 3 кадра, которые отчаянно рендерит процессор.

В качестве гостевой операционной системы использовалась Windows 10 PRO, так как, к сожалению, в серверной версии Windows 2016 браузеры не начинают использовать графический ускоритель, несмотря на то, что он фактически присутствует.

Технология RemoteFX впервые была внедрена в Windows Server 2008 R2 SP1 и включала в себя некоторое базовые возможности:

  • RemoteFX vGPU – позволила распределить ресурсы физической видеокарты на несколько виртуальных экземпляров, таким образом на виртуальных машинах Hyper-V появился настоящий 3D-рендеринг силами графического адаптера.
  • RemoteFX USB Redirection – поддержка перенаправления USB-устройств в виртуальные машины, что позволило использовать различные периферийные устройства, подключенные к «тонким клиентам»
  • RemoteFX Codec – кодек для сжатия и передачи видео и текста высокой четкости, не требующий специального оборудования и использующий ресурсы исключительно процессора

Несмотря на описанные выше возможности, популярности RemoteFX не обрел ввиду крайней ограниченности ресурсов, которые можно было бы назначить виртуальной машине, с выходом Windows Server 2012
появилось множество дополнительных функций:
  • Адаптивная графика RemoteFX – графический коннектор, динамически адаптирующийся к различным условиям работы: тип передаваемого графического контента, доступные вычислительные мощности процессора, скорость интернет-канала между сервером и клиентом, а также скорость рендеринга на стороне клиента.
  • RemoteFX для WAN – серия модификаций на сетевом уровне для поддержки UDP и обеспечения стабильного подключения как в WAN, так и в беспроводных сетях
  • RemoteFX Multi-Touch – позволила использовать тачскрины на тонких клиентах и передавать на сервер до 256 точек одновременного касания
  • RemoteFX Media Redirection API – позволила VoIP-приложениям интегрироваться с RemoteFX, обеспечив рендеринг и передачу видео и аудио контента непосредственно на стороне клиента
  • Выбор GPU – все функции RemoteFX доступны как с использованием графического процессора с программным эмулятором, так и с установленной физической видеокартой внутри сервера, что дает настоящее аппаратное ускорение
  • В RemoteFX vGPU добавлена поддержка DirectX 11

Однако, настоящий прорыв в повсеместном использовании виртуальных видеокарт на серверах под управлением Hyper-V произошел только с выходом Windows Server 2016, позволяющая явно задавать выделяемый объём видеопамяти виртуальному серверу (VPS), а сами объемы значительно выросли (до 1ГБ на каждый экземпляр), обновленный протокол RemoteFX Media Streaming начал работать для всех типов медиаконтента и полностью заменил использующийся ранее протокол MMR (Multi Media Redirection). Помимо этого, появилась поддержка OpenGL 4.4 и OpenCL 1.1 API на виртуальной машине с помощью адаптера RemoteFX.


Тест производительности видеокарты на VPS в популярном бенчмарке FurMark

Подключённая к современному VDS (виртуальному серверу) видеокарта под управлением Windows Server 2016 превращает его в полноценный домашний ПК. Данная операционная система обладает привычным пользовательским интерфейсом, мало отличимым от Windows 10. На таком сервере вы можете свободно запускать практически любое программное обеспечение и решать самые разносторонние задачи.

Без долгих ожиданий запускается самые тяжёлые графические приложения. Пример работы Autodesk 3ds Max 2019 на виртуальном сервере VPS.house:

И конечно же современные игры, в Battlefield 1 видео игры будет таким же плавным, как если бы вы запустили её на своём домашнем ПК (при хорошем интернет-соединении):

Виртуальная видеокарта QXL на реальном железе / Habr

Продолжаем переваривать специи SPICE RedHat Desktop Virtualization. В данной заметке будет рассмотрен SPICE-сервер исключительно как альтернатива VNC-серверу также будет рассмотрен эксперимент по настройке в операционной системе Fedora 17 и в операционных системах семейства Ubuntu 12.04 Precise Pangolin, например LinuxMint.

QXL vs. VNC

Виртуальная видеокарта QXL изначально была разработана для использования в эмуляторе KVM для улучшения вывода графики через протокол SPICE. С недавнего времени виртуальная видеокарта QXL может использоваться на реальном оборудовании для предоставления удаленного доступа по сети по протоколу SPICE к экрану сервера под управлением X-сервера, как альтернатива VNC-серверу.

Для запуска VNC-сервера нужен X-сервер, который должен быть запущен локально и которому для работы нужна видеокарта. В отличие от VNC-сервера, SPICE-сервер встроен в драйвер виртуальной видеокарты QXL, а как следствие может запускать X-сервер без наличия реальной видеокарты.

Работа с компьютером без использования видеокарты может использоваться не только для снижения стоимости конфигурации и использования, но также и для проброса всех установленных PCI-видеокарт в виртуальные машины спомощью технологий Vt-d и IOMMU.

Виртуальная видеокарта QXL налагает некоторые ограничения, которые необходимо учитывать при принятии решения о её использовании:

  1. Работа по выводу изображения переносится с графического процессора и памяти видеокарты на центральный процессор и оперативную память компьютера, что в свою очередь отражается на производительности. Хотя если процессор компьютера обладает несколькими ядрами и достаточным объемом оперативной памяти возрастание потребления вычислительных ресурсов будет не столь заметно.
  2. В силу переноса вычислений по обработке вывода графики с видеокарты на компьютер снижается не только производительность но и становятся недоступными некоторые возможности. Например: ускорение 3D-графики через аппаратный рендеринг, поддержка ускорения видео через оверлей и т.д. и т.п.
  3. Невозможность отладки загрузки до момента запуска X-сервера. Отладка в случае возникновения ошибок на этапе згрузки осуществляется путем подключения видео карты либо использованием SSH или вывода консоли на последовательный порт.
  4. В отличае от VNC-сервера у SPICE-сервера имеется баг суть которго заключается в том что XKB в результате запуска QXL отваливается по этой причине необходимо каждый раз при запуске инициализировать раскладки с помощью команды*:
    setxkbmap -option grp:switch,grp:alt_shift_toggle,grp_led:scroll us,ru
    

  5. В отличие от виртуальной машины, реальный компьютер не имеет виртуального канала для работы с гипервизором в следствие чего работа с буфером обмена, проброс USB-устройств будут не доступны.
  6. После установки QXL-видеокарты Х-сервер не будет использовать реальную видеокарту.

Таким образом использование виртуальной видеокарты QXL неудобно для доступа к рабочим компьютерам напрямую, но может использоваться на серверах например на узлах виртуализации. Однако стоит отметить что при желании можно виртуализовать рабочие компьютеры и удаленно пробросить в них необходимое USB-оборудование обеспечив тем самым удаленный доступ.
Установка и настройка

В качестве примера проведем эксперимент по настройке удаленного доступа через SPICE-сервер на виртуальных машинах под управлением Ubuntu 12.04 и Fedora 17 после настройки из которых удалим видеоакарты. Если эксперимент с виртуальными машинами у Вас удастся можно переходить к реальному железу.

Прежде чем приступить к эксперименту, на компьютерах под управлением операционной системы GNU/Linux семейства Ubuntu 12.04 далее (Ubuntu) подключаем репозиторий repo.umvirt.org:

sudo -i
 # становимся root
cd /etc/apt/sources.list.d
 # переходим в каталог генерации списка репозиториев
wget -q -O- http://repo.umvirt.org/umvirt.key | sudo apt-key add -
 # импортируем ключ
wget http://repo.umvirt.org/umvirt_precise.list
 # загружаем параметры доступа к репозиторию для семейства Ubuntu 12.04
apt-get update
 # обновляем списки пакетов

Внимание: в настоящее время в репозитории представлены пакеты только для платформы amd64!

На компьютерах под управлением Fedora17 (далее Fedora) подключать репозиторий не нужно. Другие версии и дистрибутивы не тестировались.

Для того чтобы приступить к использованию QXL-видеокарты нужно:

  1. Установить QXL-драйвер (как минимум версии 0.0.17) и SPICE-сервер.
    Fedora:
    yum -y install xorg-x11-server-Xspice
    

    Ubuntu:
    apt-get install xserver-xorg-video-qxl xserver-xspice
    

  2. Установить и настроить SSH для удаленного доступа к консоли:
    Fedora:
    yum -y install openssh-server
    service sshd start #Запускаем sshd
    chkconfig --level 345 sshd on #включаем автозагрузку sshd
    system-config-firewall #отключаем firewall включенный по-умолчанию
    

    Ubuntu:
    apt-get install openssh-server
    

    Если SSH-соединение работает переходим к следующему этапу
  3. Явно прописать в настройках X-сервера в файле /etc/X11/xorg.conf использование видеокарты QXL и настройки SPICE-сервера:
    Section "Device"
        Identifier "XSPICE"
        Driver "spiceqxl"
    
        # Enable regular port. Either this or SpiceTlsPort, or one of XSPICE_PORT or
        # XSPICE_TLS_PORT environment variables must be specified
        # Defaults to 5900.
        Option "SpicePort" "5900"
    
        # Do not request any password from client
        Option "SpiceDisableTicketing" "0"
    
        # Set password client will be required to produce.
        Option "SpicePassword" "password"
    EndSection
    
    Section "InputDevice"
        Identifier "XSPICE POINTER"
        Driver     "xspice pointer"
    EndSection
    
    Section "InputDevice"
        Identifier "XSPICE KEYBOARD"
        Driver     "xspice keyboard"
    EndSection
    
    Section "Monitor"
        Identifier    "Configured Monitor"
    EndSection
    
    Section "Screen"
        Identifier     "XSPICE Screen"
        Monitor        "Configured Monitor"
        Device        "XSPICE"
        DefaultDepth    24
    EndSection
    
    Section "ServerLayout"
        Identifier "XSPICE Example"
        Screen "XSPICE Screen"
        InputDevice "XSPICE KEYBOARD"
        InputDevice "XSPICE POINTER"
    EndSection
    
    # Prevent udev from loading vmmouse in a vm and crashing.
    Section "ServerFlags"
        Option "AutoAddDevices" "False"
    EndSection
    
    

    Если файл не существует его следует создать. Для удоства, через SSH и буфер обмена вы можете вставить вышеуказанный код в файл.
  4. На машине клиента нужно установить необходимые пакеты:
    Fedora:
    yum -y install spice-gtk-tools spice-client
    

    Ubuntu:
    apt-get install spice-client spice-client-gtk
    

  5. Подключиться клиентом к SPICE-сервру. Например, для доступа к SPICE-серверу расположенному по адресу 192.168.122.10 выполним команду:
    spicec -h 192.168.122.10 -p 5900 -w password
    

    или
    spicy
    


В доказательство того, что SPICE-сервер может запускать X-сервер без видеокарты, привожу скриншоты Fedora и Mint 13 Maya (семейство Ubuntu 12.04) c выводом списка PCI устройств для подтверждения с помощью команды lspci:
  1. Fedora 17
  2. Mint 13 Maya

*Способы автоматизации загрузки раскладки приведены по ссылке

Как из домашнего ПК средствами виртуализации сохранить игровую систему / Habr

Благодаря конкуренции и развитию НТП современные ПК позволяют выполнять множество простых и сложных задач одновременно, например играть и воспроизводить видео на ТВ, рендерить графику и читать новости в интернете, раздавая торренты параллельно, и т.д. и т.п. Многие идут дальше и используют несколько ПК для работы и развлечений. Однако при помощи технологий виртуализации можно с одной стороны расширить возможности своего ПК, а с другой сэкономить, т.к. по сути можно запустить несколько операционных систем на одном железе в одно и то же время.
Эта статья будет повещена настройки хоста именно для использования в «быту», т.е. разговор пойдет о GPU PASSTHROUGH.

Введение


Сперва несколько слов про виртуализацию в целом. Согласно Википедии:
Виртуализа́ция — предоставление набора вычислительных ресурсов или их логического объединения, абстрагированное от аппаратной реализации, и обеспечивающее при этом логическую изоляцию друг от друга вычислительных процессов, выполняемых на одном физическом ресурсе.
Достигается как при помощи приложений (например VirtualBox, VMware) так и на уровне систем, поддерживающих аппаратную виртуализацию (например KVM, ESXi, Hyper-V). В последнем случае потери производительности по сравнению с нативными системами минимальна.

Здесь и далее в статье будет описание настроек системы виртуализации с открытым исходным кодом Proxmox потому что она в меру дружелюбна, есть легкий доступ к консоли через веб форму, а так же базируется на связке Debian + kvm, по которым очень много гайдов и описаний в сети, т.е. документации в т.ч. и на русском языке.

Требования к железу


Нам потребуется:

— процессор и материнская плата с поддержкой VT-x, VT-d от Интел или AMD-Vi, IOMMU от АМД. Не поленитесь и уточните поддерживает ли именно Ваш экземпляр данные требования.

Что касается материнских плат. Категорически не рекомендую гнать железо при посредственной разводке на плате питания. По Z270 и Z390 игнорировать оранжевую зону или оставлять работать в стоке.

  • 2 видеокарты, одну игровую (в сети за меньшее количество проблем при пробросах в виртуальную машину хвалят красных, но лично у меня все получилось с видеокартой от зеленых), вторую для хоста. В моем случае это интегрированная в процессор.
  • 1-2 монитора и кабели к ним, для того чтобы
  • пара комплектов клавиатура + мышь, чтобы было удобно работать и настраивать системы
  • второй ПК или планшет подключенный к локальной сети, что бы сделать настройки через вебформу.

Установка и настройки


Мною было использована следующая игровая конфигурация:

— ПК для хоста конфиг был собран на далеко не лучшей материнской плате, но на англоязычных форумах очень часто хвалят эту фирму за то, что ее железо чаще всего подходит для таких вещей:
Процессор — i7 8700k
Мать — ASRock Z390M Pro4
Видеокарта — INNO3D GeForce GTX 1070 iChill X4
— второй ПК (Мини-ПК Morefine-M1s),
— 2 мыши,
— 1 клавиатуру на хосте, на остальных устройствах использовал софтварную,
— 3 подключения к монитору Dell U2713HM (VGA — для интегрированной видеокарты, HDMI — для GTX1070, на DVI находится Мини-ПК. Переключения между видеосигналами осуществлял через меню монитора)

0й этап — На материнской плате включаем VT-d:Enable, Intel Vitrualization Technology:Enable, Primary Graphx adapter:VGA, Above 4G Decoding:Enable. Если есть возможность обязательно выбираем основным графическим адаптером тот, на котором будет работать хост, т.е. более слабую видеокарту и переключаемся на нее.

1й этап — Устанавливаем Proxmox на хост. Для этого:

1.1. Скачиваем образ диска с официального сайта

1.2. Пишем образ на флешку при помощи специальных программ

1.3. Загружаемся с флешки, и производим инсталляцию с указанием на какой жесткий диск ставить, вводим пароль для будущего пользователя root, а так же настройки сети прописываем явно.

2й этап — Подключаемся по сети через веб интерфейс при помощи второго ПК или
планшета (в моем случае это был Мини-ПК) к хосту и настраиваем Proxmox по этому гайду через текстовую консоль.

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

1) Run the «dmesg | grep ecap» command.

2) On the IOMMU lines, the hexadecimal value after «ecap» indicates whether interrupt remapping is supported. If the last character of this value is an 8, 9, a, b, c, d, e, or an f, interrupt remapping is supported. For example, «ecap 1000» indicates there is no interrupt remapping support. «ecap 10207f» indicates interrupt remapping support, as the last character is an «f».

Interrupt remapping will only be enabled if every IOMMU supports it.

Если условие выполняется — продолжаем.

Итак настройки:

Открываем файл командой из консоли (символ двойной решетки вводить не надо, так я буду разделять в тексте команды от того что необходимо внести в файл)

## nano /etc/default/grub

производим замену
GRUB_CMDLINE_LINUX_DEFAULT="quiet"

для процессоров Интел
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"

для процессоров АМД
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on"

следом даем команду
## update-grub

после чего перезагружаем хост через веб интерфейсФайл grub для ПК в статье
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Proxmox Virtual Environment"
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"
GRUB_CMDLINE_LINUX=""

# Disable os-prober, it might add menu entries for each guest
GRUB_DISABLE_OS_PROBER=true

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"


Добавляем в файл конфигурации загрузку необходимых драйверов
## nano /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

Прописываем в консоли
## lspci

На экран будет выведен список устройств доступных для проброса, находим интересующий нас блок с видеокартой, в моем случае это 2 устройства в группе видеокарта и звук по адрсам 01:00.0 и 01:00.1, поэтому я прописываю сразу группу.
## nano /etc/pve/qemu-server/vmid.conf
hostpci0: 01:00

Прописываем в консоли команду для того что бы определить модель и ее id

## lspci -n -s 01:00
01:00.0 0300: 10de:1b81 (rev a2)
01:00.1 0403: 10de:10f0 (rev a1)

Теперь правим файл под нашу видеокарту (в Вашем случае id будут иные)

## nano /etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:1b81,10de:10f0

Заносим в черный лист драйвера
## nano /etc/modprobe.d/blacklist.conf
blacklist radeon
blacklist nouveau
blacklist nvidia

Теперь создаем через веб интерфейс и правим через консоль файл настроек виртуальной машины. Здесь строка «args:» решает, т.к. без нее драйвер видеокарты обнаружит виртуализацию, но путем подмены наименования оборудования, точнее hv_vendor_id=willitwork, мы снимаем проблему с ошибкой 43, которую может выдать видеодрайвер устройства. Здесь есть номер виртуальной машины в proxmox используемый в качестве имени.
## nano /etc/pve/qemu-server/<vmid>.conf
args: -cpu 'host,+kvm_pv_unhalt,+kvm_pv_eoi,hv_vendor_id=willitwork,kvm=off'
.....
bios: ovmf
.....
hostpci0: 01:00.0,pcie=1
.....
machine: q35

Файл настроек виртуальной машины для ПК в статье
args: -cpu 'host,+kvm_pv_unhalt,+kvm_pv_eoi,hv_vendor_id=willitwork,kvm=off'
bios: ovmf
boot: dcn
bootdisk: sata0
cores: 8
cpu: host
hostpci0: 01:00.0,pcie=1
ide2: local:iso/ru-en_windows_10_1803_x86-x64.iso,media$
machine: q35
memory: 16384
net0: e1000=EA:20:FA:6A:D6:A0,bridge=vmbr0
numa: 0
ostype: win10
sata0: local-lvm:vm-100-disk-0,size=120G
scsihw: virtio-scsi-pci
smbios1: uuid=751edeca-d249-4c0d-9ded-b59d929df0f1
sockets: 1
usb0: host=1-8.4
usb1: host=1-8.3
vmgenid: b75aeb27-3102-458d-8e23-18cd27796dc1


Теперь перезагружаем хост и запускаем виртуальную машину.

3й этап — Через Удаленную видеоконсоль установим Windows и драйвера. В моем случае Windows распознал сперва видео драйвер proxmox для работы через видеоконсоль, потом нашел драйвер для GTX1070, а после обновления через интернет (принудительный поиск драйверов в сети) скачал и установил нужный мне драйвер для игровой видеокарты.

4й этап — Перезапустим Виртуальную машину, переключаем отображение видеопотока на мониторе на разъем видеокарты и… в моем случае все заработало сразу, никаких ошибок 43… При этом рабочий стол определяется как №2.

я попробовал запустить видео Blue-ray — без проблем, задержек и фризов с видеорядом нет, запустил Warhammer online — он завелся и в PvP играть было комфортно, запустил GTA5 у мя выскочила сюжетка, вполне комфортно пострелял. Визуально потерь в производительности нет.

Если нам необходимо пробросить жесткий диск целиком, то в файле настроек виртуальной машины необходимо добавить строку:

ide0: volume=/dev/sda

или
sata0: volume=/dev/sda

Конкретно какой именно sda/sdb/sdc/и т.п. можно уточнить в веб интерфейсе.

P.S.

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

00:1f.0 ISA bridge: Intel Corporation Device a305 (rev 10)
00:1f.3 Audio device: Intel Corporation Device a348 (rev 10)
00:1f.4 SMBus: Intel Corporation Device a323 (rev 10)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Device a324 (rev 10)
00:1f.6 Ethernet controller: Intel Corporation Device 15bc (rev 10)

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

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

UPDATE1:
Несколько замечаний по переферии:
1. Как прокинуть в ВМ клавиатуру с порта PS/2:
сперва вводим комманду в консоли
## dmesg | grep input
Ищем в тексте запись навроде

input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2

Запоминаем цифру 2 в конце, она может быть и другой. Потом в файл настроек ВМ в строку добавляем:
args: -object ‘input-linux,id=kbd,evdev=/dev/input/event2,grab_all=on,repeat=on’
вставляя 2 в конец evdev=/dev/input/event2

Для мыши — аналогично.

2. По USB:
Что касается USB устройств там все проще, устройства прокидываются прямо из веб формы по ID или же целиком можно прокинуть порт. Однако есть нюанс — если Вы по каким-либо причинам не можете как и я прокинуть аудиоустройство в ВМ, т.к. оно содержится в группе с ключевыми контроллерами без которых хост не может полноценно работать, то проброс порта/устройства через USB решает эту проблему, но звук может начать отваливаться через некоторое время работы, шипить/гудеть и прочие… прочее, в то же время на нативной системе все будет замечательно. В этом случае необходимо пробрасывать не порт/устройство, а сам контроллер USB как PCIe устройство по методу указанному в статье. И все резко наладится. Но в то же время через хост после запуска ВМ с такими настройками пробросить другие устройства с этого контроллера больше не получится.

3. Жесткие диски можно пробрасывать как через проброс контроллера как PCIe устройство по методу указанному в статье (не рекомендую пробрасывать контроллер интегрированный в материнскую плату, только подключенные к PCIe), либо напрямую:
заходим в
## cd /dev/disk/by-id
через dir смотрим листинг…
копируем строки вида ata-WDC_WD40EFRX-68WT0N6_WD-WCC4E1АС9SХ9, в которой прописан интерфейс подключения, марка и номер серии жесткого диска. Затем открываем Файл конфигурации ВМ и пишем:
sata1: volume=/dev/disk/by-id/ata-WDC_WD40EFRX-68WT0N6_WD-WCC4E1АС9SХ9
и все работает, при этом учитывайте, что sata0-sata5, т.е. для одной ВМ число подключаемых таким образом дисков, включая виртуальных, не может превышать 6шт.

VDS с видеокартой — мы знаем толк в извращениях / RUVDS.com corporate blog / Habr

Когда один из наших сотрудников сказал своему знакомому сисадмину: «А у нас теперь новая услуга — VDS с видеокартой», тот в ответ усмехнулся: «Что, будете офисную братию на майнинг толкать?». Ну хоть не про игры пошутил, и то ладно. Много он понимает в жизни разработчика! Но в глубине души у нас затаилась мысль о том, а вдруг кто-то и правда думает, что видеокарта — удел майнеров и любителей компьютерных игр? В любом случае, лучше семь раз проверить, а заодно рассказать, зачем придуман VDS с видеокартой и почему это так важно.

Безусловно, если вам нужен арендованный виртуальный сервер VDS с видеокартой для игр, то даже не читайте дальше, переходите на страницу услуги и смотрите условия/цены от RUVDS — наверняка вам понравится. Остальных мы приглашаем к дискуссии: а нужен ли VDS с видеокартой как услуга или проще развернуть свой программно-аппаратный комплекс?

Ответ на этот вопрос зависит от бизнеса и организации его процессов. Фактически такое предложение может заинтересовать рекламные агентства с их Фотошопами и Корелами, дизайн-агентства, использующие 3D-программы, проектные организации с Автокадами. Сотрудники этих компаний смогут работать из любого места, следовательно, можно будет нанимать людей откуда угодно и при этом не тратиться на капитальные вложения в мощную технику.

Сейчас ресурсы видеокарт активно используют разработчики популярного программного обеспечения: любой современный браузер будет отрисовывать страницы сайтов значительно быстрее, если сможет использовать графический ускоритель, не говоря уже о том, что для этих самых браузеров существуют 3D приложения и игры, которые работают на WebGL.

Таким образом можно предположить, что VDS с видеокартой подойдёт многим ИТ-компаниям, интернет-магазинам, рекламным и дизайнерским агентствам, компаниям, связанным с анализом данных и т.д. Попытаемся классифицировать и подробнее описать наиболее актуальные варианты использования.

Первое, что напрашивается само собой, это работа с графикой. VDS c видеокартой обеспечит вычислительные мощности для быстрой работы с 3D-графикой, анимацией, 2D-графикой. Дизайнерам и компаниям из геймдева такая конфигурация будет оптимальна, она потянет как моделирование, так и Corel, Photoshop, Autocad и т.д. Плюс, как мы уже рассуждали ранее, у такой услуги есть важное дополнительное преимущество: компании смогут легко формировать распределённую команду и при этом не нести колоссальных затрат.

Также VDS с видеокартой могут заинтересоваться компании, у которых есть потребность в быстром обсчёте сложных задач, либо большого количества дискретных простых задач. Это компании, которые собирают и обрабатывают данные с большого количества датчиков или инфраструктуры IoT, имеют биллинг, работают с большими данными и нуждаются в ультра оперативном сборе метрик и т.д. Если вы работаете с бизнес-приложениями, основанными на Big Data, вы оцените скорость анализа и обработки данных. Вычислительные преимущества VDS с видеокартами при решении вышеперечисленных задач связаны с тем, что видеокарта обслуживается производительной оперативной памятью и имеет больше арифметико-логических модулей, чем CPU, а значит, одновременно выполняется гораздо больше операций. 

Третья по счёту и первая по важности сфера применения конфигурации VDS с видеокартой — задачи информационной безопасности такие как мониторинг и контроль трафика в нагруженных сетях, создание тестовых стендов для прогона кейсов пентест-тестирования. 

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

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

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

Из частных задач мы бы выделили две основных, которые представляют собой набор частых вычислительных операций. Первая — майнинг (а им кто-то занимается?). Вторая — более интересная и менее нагруженная. Это работа с торговыми системами типа QUIK. Работа с такой конфигурацией комфортна для высокочастотной торговли.

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

Тестирование


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

Для тестирования мы сравнили виртуальный сервер с 2 ядрами процессора и 4 ГБ оперативной памяти с виртуальной видеокартой в 128МБ и без видеокарты. На обеих виртуалках запустили в браузере Internet Explorer одну и ту же WebGL страницу. На странице рисовались квадраты размером 32×32 со скоростью 60 кадров в секунду.

Такую картинку мы получили на виртуальном сервере, с установленной видеокартой. Скорость прорисовки составила 59-62 кадра в секунду, все пространство было заполнено, число спрайтов составило 14 тысяч штук. 

Кликабельно:

Результат на аналогичном VPS без видеокарты. Скорость прорисовки 32 кадра в секунду, при полностью загруженном на 100% процессоре, имеем 1302 спрайтов, и незаполненную область.

Кликабельно:

Также мы протестировали нашу видеокарту с помощью бенчмарка FurMark, при разрешении 1920 на 1440 точек и получили среднюю частоту 45 кадров в секунду.

Кликабельно:

Еще один стресс-тест для видеокарты с помощью MSI Kombustor, здесь мы проверили видеокарту на предмет появления различных артефактов. При тестировании на экране не должны появляться разноцветные пятна, геометрические фигуры, полосы и прочие артефакты. После 25 минут тестирования видеокарты все в норме, артефактов не появилось. 

Запустили видео на youtube в 4к. Кликабельно:

Также мы запустили тесты в 3DMark. Получили в среднем около 40 кадров в секунду. 

Провели тест с помощью бенчмарка Geekbench 5 для OpenCL

Результаты тестов нас приятно порадовали. Пробуйте, тестируйте, делитесь опытом.

Кстати, а кто-то уже пробовал конфигурацию VDS с видеокартой, для чего использовали, как оно вам? 

3D ускорение VDI на практике. Часть 1 / ИТ-ГРАД corporate blog / Habr

3D ускорение VDI на практике.

Часть 1 — vSGA и vDGA

Отсутствие аппаратного ускорения графики является существенным препятствием при внедрении технологий виртуализации в компаниях, работающих в сфере дизайна, проектирования, конструкторских разработок и пр. Рассмотрим, какие новые возможности появились с выходом NVIDIA GRID.

Виртуализация рабочих мест (VDI) уже прочно вошла в нашу жизнь, в первую очередь в корпоративном сегменте рынка, и уверенно пробивает путь в остальные сегменты, в том числе и в виде публичных облачных сервисов (Desktop as a Service). Отсутствие же аппаратного ускорения графики сдерживает использование данной технологии в тех отраслях, которые могли бы оценить такие преимущества использования VDI как удаленную доступность, безопасность данных и упрощение аутсорсинга персонала.

Первые шаги к использованию 3D ускорения в VDI были сделаны достаточно давно и заключались в пробросе PCI устройств в виртуальные машины, что позволяло выдавать для VDI видеокарты, установленные в сервер или подключенные к серверу с помощью внешних PCIe корзин, например, таких как Dell PowerEdge C410x. Недостатки такого решения очевидны — повышенное использование электроэнергии, места в стойках и высокая стоимость.

Коротко о технологии NVIDIA GRID

С анонсом технологии NVIDIA GRID (NVIDIA VGX на момент анонса) в прошлом году интерес к использованию 3D ускоренных VDI значительно возрос. Суть технологии GRID, которая исходно предназначена именно для 3D ускорения в виртуальных средах, достаточно проста и включает в себя следующие принципы:
  • Агрегация на базе одной PCIe карты нескольких графических ускорителей;
  • Возможность виртуализации графических ускорителей на уровне гипервизора;
  • Возможность виртуализации графических ускорителей средствами технологии GRID Virtual GPU.

На данный момент компанией NVIDIA выпущено две видеокарты построенных на базе архитектуры NVIDIA Keppler — NVIDIA GRID K1 и K2. Характеристики данных карт следующие:
                 GRID K1                                                                GRID K2                            
Число GPU 4 Kepler GPU начального уровня 2 Kepler GPU высокого класса
Ядра CUDA 768 3072
Общий размер памяти 16 ГБ DDR3 8 ГБ GDDR5
Максимальная мощность 130 Вт 225 Вт
Длина Карты 26,7 см 26,7 см
Высота Карты 11,2 см 11,2 см
Ширина Карты Dual Slot Dual Slot
Отображение

 ввода/вывода данных

Нет Нет
Дополнительное питание Разъем 6-pin Разъем 8-pin
PCIe x16 x16
Поколение PCIe Gen3 (совместим с Gen2) Gen3 (совместим с Gen2)
Охлаждение Пассивное Пассивное     
Технические спецификации Спецификации платы GRID K1 Спецификации платы GRID  K2

Фактически, GRID K1 представляет собой интегрированные на одной PCIe карте четыре карты уровня QUADRO K600, карты GRID K2 — две карты уровня QUADRO K5000. Это позволяет даже без использования виртуализации существенно увеличить плотность графических адаптеров в серверах.

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

ПО, поддерживающее технологию GRID — это гипервизоры VMware, Citrix и Microsoft, а также системы виртуализации рабочих станций VMware и Citrix (и Microsoft, если рассматривать варианты общего доступа к серверу).

Описание нашего тестового стенда

Для нашего тестового стенда мы решили использовать 1U сервер SuperMicro 1027GR-TRFT.
Его основные особенности:
  • Dual socket R (LGA 2011) supports Intel® Xeon® processor E5-2600 and E5-2600 v2 family
  • Up to 512GB ECC DDR3, up to 1866MHz; 8x DIMM sockets
  • 3x PCI-E 3.0 x16 slots (support GPU/Xeon Phi cards), 1x PCI-E 3.0 x8 (in x16) low-profile slot
  • Intel® X540 10GBase-T Controller
  • 4x Hot-swap 2.5″ SATA3 Drive Bays
  • 1800W Redundant Power Supplies Platinum Level (94%+)

Такой выбор был обусловлен высокой плотностью (до 3 видеокарт GRID в 1U) и наличию встроенных 10GBase-T сетевых интерфейсов.

SATA корзина позволяет использовать недорогие SSD диски для Host Based кэширования доступа к данных, столь полезного при VDI нагрузках, с характерными пиками дисковой активности в начале и окончании рабочего дня.

При современных же ценах на модули памяти восьми DIMM-слотов оказывается вполне достаточно в ситуации, когда плотность VM на сервер ограничивается CPU и GPU ресурсами.

В данный сервер мы установили карту NVIDIA GRID K1. Приводим фото сервера с готовой к установке видеокартой:

В качестве платформы виртуализации была выбрана привычная нам VMware vSphere. Забегая вперед, отмечу, что во второй части данной статьи нам придется использовать Citrix XenServer, поскольку на данный момент только он и только в статусе Tech Preview поддерживает технологию GRID Virtual GPU.

Гипервизор ESXi определяет видеокарту как 4 устройства NVIDIAGRID K1, подключённые через PCI/PCI bridge, что делает ускорители доступными для раздельного использования как passthrough устройства, подключаемые к ВМ, или как основу для виртуализации на уровне гипервизора.

В гипервизор инсталлируется драйвер от NVIDIA:

~ # esxcli software vib list | grep NVIDIA
NVIDIA-VMware_ESXi_5.1_Host_Driver 304.76-1OEM.510.0.0.802205 NVIDIA VMwareAccepted 2013-03-26

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

2013-10-28T06:12:42.521Z cpu7:9838)Loading module nvidia ...
2013-10-28T06:12:42.535Z cpu7:9838)Elf: 1852: module nvidia has license NVIDIA
2013-10-28T06:12:42.692Z cpu7:9838)module heap: Initial heap size: 8388608, max heap size: 68476928
2013-10-28T06:12:42.692Z cpu7:9838)vmklnx_module_mempool_init: Mempool max 68476928 being used for module: 77
2013-10-28T06:12:42.693Z cpu7:9838)vmk_MemPoolCreate passed for 2048 pages
2013-10-28T06:12:42.693Z cpu7:9838)module heap: using memType 2
2013-10-28T06:12:42.693Z cpu7:9838)module heap vmklnx_nvidia: creation succeeded. id = 0x410037000000
2013-10-28T06:12:42.943Z cpu7:9838)PCI: driver nvidia is looking for devices
2013-10-28T06:12:42.943Z cpu7:9838)PCI: driver nvidia claimed device 0000:86:00.0
2013-10-28T06:12:42.943Z cpu7:9838)PCI: driver nvidia claimed device 0000:87:00.0
2013-10-28T06:12:42.943Z cpu7:9838)PCI: driver nvidia claimed 2 devices
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 304.76 Sun Jan 13 20:13:01 PST 2013
2013-10-28T06:12:42.944Z cpu7:9838)Mod: 4485: Initialization of nvidia succeeded with module ID 77.
2013-10-28T06:12:42.944Z cpu7:9838)nvidia loaded successfully.
После загрузки гипервизора

В качестве платформы для создания инфраструктуры VDI используется продукт Citrix XenDesktop 7, который в настоящий момент используется и в нашей production инфраструктуре, предоставляющей сервисы VDI для наших заказчиков. На тестовых машинах используется технология HXD 3D Pro, осуществляющая эффективную упаковку и проброс на клиента отрендеренного GPU изображения. Тестовый виртуальный сервер имеет следующую конфигурацию: 4vCPU 2GHz, 8GB RAM, 60GB HDD.

Тестирование vSGA

vSGA — это технология VMware, обеспечивающая виртуализацию ресурсов GPU, установленных в сервера под управлением гипервизора VMware ESXi, и последующее использование данных GPU для обеспечения 3D ускорения для виртуальных видеокарты, выданных для виртуального сервера.

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

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

Функциональность виртуальной видеокарты следующая:

  • поддерживаемые API: DirectX 9, OpenGL 2.1
  • максимальный объем видеопамяти: 512MB
  • производительность графического ядра: динамическая, не управляется.

В случае использование VMware View такую конфигурацию виртуальных машин можно осуществить непосредственно из интерфейса управления View, в нашем же случае для активации аппаратного ускорения для виртуальной видеокарты необходимо произвести два действия:
  1. включить поддержку 3D,
  2. установить размер видеопамяти в свойствах видеокарты в редактировании машины:

и добавить параметр mks.use3dRenderer = hardware в ее параметры:

В гостевой ОС такая виртуальная видеокарта определяется как «VMware SVGA 3D». Она отличается от обычной виртуальной видеокарты только объемом памяти и поддержкой аппаратного ускорения вышеперечисленных API.

Результаты выполнения теста FurMark на такой VDI машине однозначно говорят, что играть на ней не придется (при этом необходимо отметить, что во время тестирования физической видеокартой пользовалась одна виртуальная машина, то есть все вычислительные ресурсы видеокарты, с учетом накладных расходов виртуализации, были доступны тесту):

С точки зрения AutoCad 2014 возможности видеокарты выглядят следующим образом:

Enhanced 3D Performance: Available and on
Smooth display: Available and off
Gooch shader: Available and using hardware
Per-pixel lighting: Available and on
Full-shadow display: Available and on
Texture compression: Available and off
Advanced material effects: Available and on
Autodesk driver: Not Certified
Effect support:
Enhanced 3D Performance: Available
Smooth display: Available
Gooch shader: Available
Per-pixel lighting: Available
Full-shadow display: Available
Texture compression: Available
Advanced material effects: Available

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

Результаты выполнения теста Cadalyst Benchmark:

Результаты не впечатляю, однако использовать данное ПО можно, а если большой производительности и работы со сложными моделями не требуется — например, в учебном классе, то высокая плотность и низкая стоимость таких машин может оказаться полезной.

Тестирование vDGA

vDGA — это название, используемое VMware для обозначения проброса физической видеокарты в виртуальную машину.

Фактически, для данной технологии NVIDIA GRID дала одно единственное преимущество — высокую плотность GPU, которая позволяет отказаться от использования внешних PCIe корзин.

Например, в используемый на тестовом стенде сервер возможно установить три видеокарты NVIDIA GRID K1, что даст нам 12 независимых ускорителей класса QUADRO K600. Это позволяет запустить на сервере 12 виртуальных серверов, что позволяет загрузить мощности сервера, а в зависимости от профиля нагрузки — и дает запас по GPU ресурсам по сравнению с CPU ресурсами.

Для проброса видеокарты в виртуальный сервер необходимо включить режим passthrough для данного PCIe устройства в конфигурации хоста и добавить PCI устройство в конфигурацию виртуальной машины:

Также, требуется установить полное резервирование памяти для данной виртуальной машины

и провести настройку pci hole. На этот счет существуют различные мнения, мы выбрали значения от 1200 до 2200:

В гостевой ОС в таком случае видеокарта видится полноценным устройство от NVIDIA и требует установки драйверов для семейства видеокарт GRID.

Результаты FurMark близки к результатам, полученным в тесте vSGA, что говорит об относительной эффективности уровня виртуализации для этого теста:

При использовании AutoCad 2014 картина следующая:

Current Effect Status:
Enhanced 3D Performance: Available and on Smooth display: Available and off
Gooch shader: Available and using hardware
Per-pixel lighting: Available and on
Full-shadow display: Available and on
Texture compression: Available and off
Advanced material effects: Available and on
Autodesk driver: Not Certified
Effect support:
Enhanced 3D Performance: Available
Smooth display: Available
Gooch shader: Available
Per-pixel lighting: Available
Full-shadow display: Available
Texture compression: Available
Advanced material effects: Available

Все возможности также ожидаемо поддерживаются, однако карточка не является сертифицированной. Из серии GRID для AutoCad сертифицирована только K2.

Результаты выполнения бенчмарка Cadalyst 2012:

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

Если же производительности карты K1 не достаточно, можно установить K2 и получить top range видеокарту внутри виртуального сервера.

Во второй части статьи

Мы подробно расскажем о возможности виртуализации GPU посредством технологий NVIDIA, которые обещают нам поддержку всех доступных физической карте API и производительность, достаточную для уверенной работы с CAD, покажем тестовый стенд, замеры производительности таких видеокарт и подведем итоги. Продолжение следует.

Виртуальные GPU / ИТ-ГРАД corporate blog / Habr

Объемы данных, накапливаемых в мире, растут, поэтому появляются все новые способы их обработки. Один из способов повышения скорости вычислений – совместное использование центрального (CPU) и графического процессора (GPU). Вычисления с GPU-ускорением были придуманы еще в 2007 году компанией Nvidia, но теперь технология вышла на новый уровень и применяется в дата-центрах крупнейших научных лабораторий и предприятий.

Мы уже затрагивали тему виртуализации в своем блоге, когда говорили о том, как и кем используется виртуальная инфраструктура. Сегодня нам бы хотелось рассказать вам, как работают виртуальные графические процессоры и какие GPU-технологии существуют на рынке.



Вычисления на GPU используются не только в компьютерных играх и при работе с видеоконтентом. Например, NASA, по заявлению одного из ученых-метеорологов, использует GPU в моделях GEOS-5 для увеличения эффективности численного моделирования атмосферных явлений. Это позволяет повысить доступность системы для большего числа людей, гарантируя разрешение 100–200 км/пиксель.

Вычисления с GPU-ускорением применяются и в бизнес-аналитике. Так, по словам старшего научного сотрудника HP Labs Рена Ву (Ren Wu), GPU позволили увеличить производительность используемых аналитических систем в 5–20 раз.


Сравнение центрального и графического процессоров

Архитектуры CPU и GPU изначально «заточены» под решение разных задач. Центральный процессор решает задачи общего назначения: исполнение набора последовательных инструкций, управление периферийными устройствами и так далее, поэтому обычно он содержит от 2 до 18 ядер, имеющих сложную структуру.

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


/ фото Mmanss CC

Использование подобного рода вычислений актуально в научной сфере, поэтому для выполнения объемных научных расчетов создаются суперкомпьютеры, «начиненные» GPU. Однако несмотря на все преимущества подобного рода вычислений, закупка физического оборудования выливается в серьезные денежные траты. Более того, «железо» имеет тенденцию к устареванию, потому его приходится регулярно обновлять.

Технология vGPU


Эти проблемы призвана решить технология виртуальных графических процессоров (vGPU), представленная Nvidia, которая дает пользователям возможность удаленно запускать графикоемкие приложения. Здесь стоит отметить, что до появления vGPU применялись другие методы ускорения обработки графики:
  • Virtual Shared Graphics Acceleration (vSGA) – предполагает совместное использование разными виртуальными рабочими столами физических GPU.
  • Virtual Dedicated Graphics Acceleration (vDGA) – выделение физического GPU на виртуальной машине за счет проброса (pass-through) устройства, однако в этом случае ВМ оказывалась привязана к хосту, что выливалось в проблему, связанную с ограничением числа GPU, устанавливаемых на хост.

Технология же vGPU вобрала в себя лучшее от этих двух подходов. Как и в случае vSGA, в среде vGPU предполагается совместное использование GPU и RAM несколькими виртуальными рабочими столами, но при этом каждая ВМ использует драйверы Nvidia передает команды напрямую к GPU, как в случае с vDGA.

Такой решение, как показало тестирование, проведенное сотрудниками компании VMware, оказалось достаточно состоятельным. В своей работе они описали результаты тестов приложений с использованием продуктов VMware: Workstation 6.5 и Fusion 2.0. Им удалось установить, что производительность Half-Life 2: Episode 2 и Civilization 4 при использовании виртуальных GPU была близка к фактической (как если бы игры запускали на физической машине).

Но технология vGPU находит применение в самых разных сферах: архитекторы и инженеры используют её в системах автоматизированного проектирования (например в Autodesk BIM), а дизайнеры работают с цифровым фото- и видеоконтентом (например в Adobe Photoshop). Она также применяется работниками из сферы здравоохранения, которые пользуются системами передачи и архивации медицинских изображений и документов обследованных пациентов (PACS), такими как GE Centricity EMR.

Стоит отметить, что до недавних пор невозможно было организовать доступ множества пользователей к одному GPU. Если 32 человека хотели обратиться к чертежам в AutoCAD со своих ВМ, то приходилось приобретать 8 дорогих видеокарт с 4 GPU. Эту проблему решила технология Nvidia GRID. Её суть заключается в совместном использовании vGPU несколькими виртуальными десктопами, к которым предоставляется прямой доступ с помощью драйверов Nvidia.

Фактически последняя версия Nvidia GRID 2.0 позволяет перенести всю работу в виртуальное пространство. Обновленная технология поддерживает до 128 пользователей на сервере и значительно увеличивает производительность приложений. Также GRID 2.0 позволяет запускать виртуальные десктопы на блейд-серверах и поддерживает не только ОС Windows, но и Linux.

Настройка режима vGPU для карт Nvidia в VMware vSphere 6



/ фото ChrisDag CC

Компания VMware ввела функцию виртуальных GPU в обновлении своей платформы виртуализации vSphere 6.0. Технология vGPU от Nvidia при использовании с продуктами VMware подразумевает использование в качестве платформы VMware vSphere 6, а в качестве средства управления виртуальными ПК – VMware Horizon 6.

vGPU поддерживается для графических адаптеров Nvidia GRID K1 и K2, для каждого из которых определены 4 профиля использования ресурсов видеокарты. Вот таблица их вариантов:

В данной таблице приведены три типа пользователей:

  • Дизайнер – человек, который использует «жадные» до графических ресурсов приложения (сюда относятся и пользователи CAD-приложений).
  • Продвинутый пользователь – человек, использующий подобные приложения время от времени.
  • Информационный работник – пользователь, слабо использующий ресурсы видеокарты.

В целом для настройки vGPU с VMware vSphere 6 необходимы следующие компоненты:
  • VMware vCenter 6.0,
  • VMware ESXi 6.0,
  • VMware Horizon View 6.1,
  • Nvidia GRID vGPU Manager.

Сперва нам потребуется настроить на серверах BIOS, причем для каждого вендора будут свои параметры. Вот, например, конфигурация для Cisco:
  • CPU Performance: установить Enterprise или High Throughput.
  • Energy Performance: выбрать пункт Performance.
  • PCI Configuration: выставить MMCFG BASE в 2 GB и отключить Memory Mapped I/O above 4GB.
  • VGA Priority: выставить в Onboard VGA Primary.

Далее, нужно развернуть на хостах компонент Nvidia vGPU Manager, который создает связь между графическими процессорами видеокарты и виртуальной машиной. Устанавливается он как обычный VIB-пакет.

После того как Nvidia vGPU Manager настроен на хост-серверах ESXi, нам нужно подготовить виртуальные машины. Это делается через vSphere Web Client, где выбираются аппаратные характеристики ВМ в зависимости от типа рабочей нагрузки.

Затем в настройках ВМ нужно добавить Shared PCI Device, а также выбрать тип Nvidia GRID vGPU и профиль в соответствии с приведенной выше таблицей. После этого можно устанавливать гостевую ОС (Windows 7 и более поздние версии).

Теперь остается установить драйвер Nvidia GRID и настроить пул виртуальных ПК в VMware Horizon View: просто указываем протокол PCoIP и тип 3D-рендера Nvidia GRID VGPU. На этом все. Виртуальные машины готовы к работе с vGPU.

P.S. Интересные материалы из нашего блога по теме виртуализации:

Проброс видеокарты в виртуальную машину / Habr

Говорят, что современные аппаратные технологии поддержки виртуализации (VT-d у Intel, IOMMU у AMD) позволяют отдавать физическое устройство на шине PCI в непосредственное управление виртуальной машине. В том числе видеокарту.
Воображение рисует такую конфигурацию: настольный сервер с гипервизором, на нем запускается гостевая пользовательская операционная система, имеющая доступ к необходимым устройствам ввода-вывода, один-два неприхотливых сервера по мере надобности, ну и сколько надо виртуалок для бесчеловечных экспериментов. Управляем гипервизором через консоль в гостевой ОС либо удаленно, с ноутбука, скажем.
Вдохновленный этой картиной, я решил попробовать, но оказалось, что проброс (passthrough) видеоадаптера — задача не совсем тривиальная. Только месяца через три боданий с железом и чтения форумов удалось получить положительный результат. В качестве гипервизора пробовал VMware и Xen. Получилось только с Xen.

Коротко.
Железо:
  • Материнская плата Gigabyte GA-Q67M-D2H-B3
    Прошивка BIOS — F5
    Setup: CPU->Intel Virtualization Technology=ON
    Setup: Chipset->North Bridge->VT-d=ON
  • Процессор Intel Core i5 2500 3.3 GHz
  • Память 16 GB
  • ATI Radeon HD 3470 в первом слоте PCIe, используется гипервизором
  • ATI Radeon HD 3450 во втором слоте PCIe, отдается гостевой ОС
  • Сетевой адаптер Intel в слоте PCI

Софт:
  • XCP (Xen Cloud Platform) 1.0 (XenServer build 42052c)
  • Citrix XenCenter для управления
  • Windows 7 64 bit в качестве гостевой ОС, ATI Catalyst 12.1

Поначалу я долго экспериментировал с VMware vSphere 5.0. Собственно, аппаратная конфигурация подбиралась именно под нее. По дороге открылся ряд интересных подробностей: например, VT-d должен поддерживаться и процессором (пишут, что процессоры с индексом K не годятся), и чипсетом и материнской платой. С видеокартами вообще беда: известно, что с большинством этот фокус не проходит, с некоторыми (довольно короткий список) у одних получается, у других нет. Долгое и содержательное (хотя не слишком радостное) обсуждение было тут:
VMware Communities: VMDirectPath and ATI Radeon. Radeon 3450 ходил, пожалуй, в фаворитах как одна из самых пробрасываемых карт.
Я перебрал приличное количество разнообразных комбинаций железа. В конкурсе участвовали две материнские платы, три видеокарты плюс интегрированное видео SandyBridge (IGD), три сетевых адаптера и один процессор. Несколько раз я бросал эти бесплодные попытки на неделю-другую, потом придумывались какие-то варианты. По дороге был один момент, когда почти получилось: виртуалка правильно определила монитор, но дальше дело не пошло. Уперся в то, что карта вроде бы нормально пробрасывалась в виртуалку, и в девайс менеджере показывалась ровно, но Каталист упорно отказывался иметь с ней дело. Карта как живая, но не работает.

Можно было попробовать много чего еще: Windows XP и Linux в качестве гостевых систем (ставил Windows 7 в 32 и 64-разрядном исполнении), добыть очередную видеокарту… В конце концов плюнул и решил зайти с другого конца, попробовав другой гипервизор. Не мудрствуя, взял то, что на виду: Xen в составе Xen Cloud Platform(XCP).
XCP поставился без сучка без задоринки.

На некоторое время поставил в тупик вопрос: как этой системой рулить? В смысле, должна же быть какая-нибудь консоль управления, желательно под винды? Поковырявшись полдня с условно-штатным OpenXenManager я пришел к мысли, что то ли лыжи не едут, то ли эта кроссплатформенная тулза на винде не живет. Один или два раза она сконнектилась с сервером, но померла где-то в процессе работы, остальные разы глухо висла при коннекте, сливая неудежимый поток исключений в консоль Питона.
К счастью, более широкий взгляд в окружающий интернет открыл мне, что Citrix XenCenter прекрасно может рулить opensource-ным Xen-ом, а сам вполне бесплатен. Правда, при коннекте кричит, что через N дней у вашего сервера истечет Evaluation period, но знающие люди пишут, что это он просто не в курсе насчет opensource редакции сервера, а на самом деле все будет работать.
XenCenter позволяет создавать-включать-гасить виртуалки, а проброс устройств надо настраивать из sysadmin-friendly интерфейса командной строки.

Против ожиданий, проблем тут не случилось. Сделал все по мануалу, и хватило его одного. Вот народ жалуется, что по Xen-у документации мало. Так другой раз и хорошо, что мало, если этого хватает. Сколько я по vSphere прочел, и все без толку… Впрочем, не хочу говорить дурных слов про vSphere. Под ней зато так железо настроилось, что Xen пролетел прямо со свистом.
Итак, с помощью XenCenter я организовал виртуалку о двух ядрах и 4 ГБ памяти, накатил туда седьмую 64-битную винду и пошел пробрасывать.

В соответстви с руководством правим /boot/extlinux.conf, вставляя строку "iommu=1 iommu_inclusive_mapping=1" после каждого вхождения "/boot/xen.gz"
Выполняем extlinux /boot.
Шаги, связанные с модулем pciback, пропускаем — пишут, что в шестерке он уже вкомпилирован в ядро.
Делаем xe vm-list и находим uuid нашей виртуалки, у меня uuid=d103a91d-5c38-844f-14d5-64b3c495eb08
Выполняем команду lspci и находим в выводе нашу карту, например 02:00.0 VGA compatible …, 02:00.1 Audio… (двойка удивительным образом соответствует номеру слота, куда воткнута карта).
Записываем однострочный скрипт вида
xe vm-param-set other-config:pci=0/0000:02:00.0,0/0000:02:00.1 uuid=d103a91d-5c38-844f-14d5-64b3c495eb08
У меня на карте, помимо видеоадаптера, еще звук — поэтому, помня грабли, на которые наступал в vSphere, добавляю оба устройства: 0/0000:02:00.0, 0/0000:02:00.1.
Выполняем скрипт. Для контроля xe vm-param-list uuid=d103a91d-5c38-844f-14d5-64b3c495eb08 | more — действительно
Останавливаем и снова запускаем виртуалку (пишут, что именно так, а не ребутом — не стану проверять лишний раз).
При первой попытке карта у меня в первом слоте PCIe (01:00.0, 01:00.1) и по умолчанию используется гипервизором. После перезапуска виртуалки монитор гаснет.
В XenCenter (с ноутбука) заходим в консоль виртуалки и после логина в винду видим, что она просит ребута. Признак того, что она нашла новое устройство. Не будем ей отказывать. Ребут. Действительно, в Device Manager появился новый видеоадаптер Radeon 3450 с драйвером Microsoft WDDM 1.1. Из предыдущего опыта известно, что драйвер нужен родной. Качаю и ставлю свежий ATI Catalist 12.1, тот после установки, как обычно просит ребута. Ребут… опаньки. Первая попытка накрывается медным тазом: падает гипервизор. Да… vSphere в такой ситуации одерживала убедительную победу над виртуалкой, устраивая ей BSOD.
Перепускаем хост и, по рекомендации лучших собаководов, смотрим, что пишет нам команда
dmesg. Пишет она, помимо прочего, такое:

pciback 0000:01:00.1: secondary bus reset failed for device — all functions need to be co-assigned — err: 6
pciback 0000:01:00.1: FLR functionality not supported; attempts to use secondary bus reset unsuccessful;
pciback 0000:01:00.1: FLR not performed for device

Похоже, что передача карты на горячую нам не светит. Ладно. Дадим гипервизору свой VGA адаптер, благо видеокарт мне теперь хватает. Переставляем Radeon 3450 во второй слот, в первый ставим валяющийся рядом 3470. К каждой карте прицепляем по монитору. Включаем хост, запускаем виртуалку. Винда просит перезагрузки после изменения конфигурации. Ребут. Логинимся…

В консоли XenCenter заставка зависает, и я не сразу соображаю, что правый монитор светится синим


Оно все-таки произошло.
Итого, на Xen срослось за 3 дня (после того, как 3 месяца упражнялся на VMware).

Я залогинился. Картинка на мониторе самая обыкновенная, без особенностей. Разрешение 1920х1200 держит. Не тупит (хотя тестов не гонял). Видео с YouTube проигрывается нормально.

На этой радостной ноте завершу свой правдивый отчет, а сам займусь пробросом клавиатуры, мыши и прочей периферии.

Update:
Пробросил клавиатуру и мышь, пишу из виртуалки под Win7. Здесь ничего, жить можно.
Индекс производительности 3.5

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

Проброс USB сделал грубо и цинично:
xe vm-param-set other-config:pci=0/0000:02:00.0,0/0000:02:00.1,0/0000:00:1a.0,0/0000:00:1d.0 uuid=d103a91d-5c38-844f-14d5-64b3c495eb08
То есть пожертвовал виртуалке USB контроллеры. С другой стороны, Xen пока без них обойдется.

Что еще? Поставил XenCenter, Xen нормально администрится (кто бы сомневался). Внешний USB-диск, естественно, тоже нормально прицепляется. Теперь надо понять, как пробрасывать CD-ROM.

К сожалению, ничего не вышло у меня с USB Passthrough, равно как и со справедливо упомянутым в комментариях Xen VGA Passthrough (Scraelos), потому как нет под XCP файла «/etc/xen/ cfgfile». Как прописать необходимые настройки с помощью xe — я не разобрался. Если знатоки Xen помогут, буду очень признателен.

Update: ToDo:

  • Пробросить CD-ROM (-)
  • Сконфигурировать статический IP (+)
  • Протестировать производительность (частично сделано)
  • Попробовать пересадить dom0 на IGD, освободится один слот PCIe (-)
  • Попробовать пересадить dom0 на onboard NIC, освободится слот PCI (+)
  • Попробовать впарить dom0 клавиатуру на PS/2
  • Организовать файловую систему для обмена даными между гостевыми ОС
  • Организовать переключение между гостевыми ОС (скриптами, наверное)

Update 06.02.2012:
dom0 на IGD пересаживаться отказался в категорической форме. Кроме того, повторил попытку пробросить primary VGA adapter — без толку. Вернулся к прежней конфигурации адаптеров.
Уперся в проблему с пробросом CD(DVD)-Writer. CD-ROM пробрасывается штатно, но только RO, а мне надо RW. По этому поводу нашел 2 рекомендации: воткнуть и пробросить отдельный SATA контроллер и использовать USB CD/DVD-Writer (благо USB пробрасывается). К сожалению, даже эти (имхо, костыльные) решения у меня на данный момент не заработали. Контроллер пробрасываться отказался. Попытка подключить штатный SATA CD/DVD привод через переходник USB-SATA ни к чему хорошему не привела. Продолжаю опыты.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *