Коли ми починаємо використовувати віртуалізацію не лише для тестування кількох речей, рано чи пізно виникає те саме питання: чому моя віртуальна машина працює безперебійно з процесором і диском, але... Графіка здається повільною, уривчастою та має гірший час відгуку. А як щодо системи, встановленої безпосередньо на апаратному забезпеченні? У сценаріях настільного комп'ютера, легких іграх, відео чи роботі в 3D ця різниця дуже помітна.
Ключовим є розуміння того, що продуктивність графіки у віртуальних машинах залежить не лише від графічного процесора: гіпервізор, тип віртуалізації графічного процесора, процесор, оперативна пам'ять, сховище та навіть налаштування монітора – все це відіграє певну роль. Якщо ви хочете, щоб ваші віртуальні робочі столи наближалися до роботи з системою "голе залізо" на сучасному ноутбуці або ПК, вам потрібно добре поєднувати апаратне забезпечення, гіпервізор та такі технології, як SR-IOV, passthrough, спільне використання GPU або 3D-прискорення.
Порівняння графічної продуктивності у віртуальних машинах та фізичних системах
На фізичному сервері або ПК операційна система безпосередньо взаємодіє з графічним процесором, процесором, оперативною пам'яттю та сховищем, тому Продуктивність процесора, пам'яті та диска зазвичай максимальна.без проміжних шарів. У віртуальній машині графічний процесор та решта пристроїв представлені через віртуальне обладнання, і цей рівень абстракції додає певних накладних витрат.
Хоча типові тести продуктивності показують, що навіть у високооптимізованих середовищах, Процесор у віртуальній машині може втратити близько 5-8% потужності Порівняно з тією ж системою на голому металі, продуктивність оперативної пам'яті може знизитися на 7-13%, а обсяг дискового вводу-виводу (наприклад, у блоках 4 КБ) може зменшитися більш ніж на 15-25%. Хоча це може бути прийнятним на серверах, у Інтерактивна графіка та відео призводять до невеликих накопичених затримокМенш плавне прокручування та гірший загальний досвід.
Ось чому багато адміністраторів досі надають перевагу фізичним серверам для дуже вимогливих баз даних, інтенсивного рендерингу або робочих навантажень у реальному часі, тоді як для веб-сервіси, мікросервіси, тестові середовища або офісні робочі столи Віртуалізація пропонує чудове співвідношення гнучкості та продуктивності.
Графічний процесор ще більше ускладнює ситуацію: віртуалізація процесора та оперативної пам'яті є дуже зрілою, але віртуалізація графіки все ще відстає. обмеження залежно від виробника, гіпервізора та діапазону картСаме тут і стають у пригоді такі технології, як SR-IOV, розділення на графічному процесорі, пряме пропускання або специфічні рішення від VMware, NVIDIA чи Microsoft.
Типова проблема: хороша продуктивність на хості, погані відчуття у віртуальній машині
Дуже поширеним є випадок, коли хтось користується сучасним ноутбуком, наприклад, з AMD Ryzen 7 з інтегрованим графічним процесором iGPU та 4K-дисплеємде хост-система (Debian, Windows чи будь-яка інша) працює ідеально: переміщення вікон відбувається миттєво, важкі веб-сайти реагують добре, а YouTube працює у роздільній здатності 4K без проблем.
Коли KVM/QEMU налаштовано з Debian 12 як хостом, а віртуальні машини також створені з Debian за допомогою графіки Virtio, інтерфейс змінюється: хоча робочий стіл реагує, Вебсайти з великою кількістю JavaScript, потокове відео Або ж під час прокручування в повноекранному режимі вони демонструють заїкання та затримки, яких немає на хості. Спроби ввімкнути VirGL для 3D-прискорення у віртуальній машині призвели до погіршення продуктивності віртуального робочого столу замість покращення.
У таких сценаріях логічне питання полягає в тому, чи є рішення: перейти на графічний процесор із SR-IOV, придбати нову систему на базі Intel Lunar Lake з графікою Xe2, обрати вежу з дискретним графічним процесором чи обрати... «Груба сила» процесора з сучасним Ryzen 9 та багатьма ядрамиТакож існують сумніви щодо того, чи такі технології, як SR-IOV, справді є тією панацеєю, яку обіцяють деякі виробники.
Реальність така Немає єдиного чарівного рішення.Покращення графічної продуктивності віртуальної машини включає налаштування кількох компонентів: вибору графічного процесора, типу віртуалізації графіки, пропускної здатності пам'яті, драйверів гостьових систем, налаштувань відео в гіпервізорі та навіть роздільної здатності екрана та кількості моніторів.
SR-IOV, passthrough та спільний графічний процесор: підходи до віртуалізації графіки
Щоб зрозуміти, чого можна очікувати від кожного варіанта, необхідно розрізняти три основні підходи: Пряме пропускання через GPU, SR-IOV (або еквівалентні технології) та «чиста» віртуалізація програмного забезпечення де графічний процесор повністю абстрагований.
Пряме виділення даних через графічний процесор (passhrough)
У класичному пассивному режимі гіпервізор «доставляє» повний фізичний графічний процесор до однієї віртуальної машини, щоб Ця віртуальна машина бачить карту так, ніби вона встановлена у фізичній системі.Зазвичай це пропонує найкращу можливу продуктивність, ідеальну для ігор, просунутого САПР, штучного інтелекту або інтенсивного рендерингу.
Недоліком є те, що ви зазвичай втрачаєте можливість спільний доступ до цього графічного процесора між хостом та іншими віртуальними машинамиУ середовищі робочого столу це проблема: вам доведеться використовувати окремі відеовиходи або вдаватися до таких рішень, як Looking Glass, щоб переглядати віртуальну машину на одному моніторі, що додає складності та залежностей. Це не найзручніше рішення, якщо ви хочете використовувати хост і віртуальні машини одночасно на одному екрані.
SR-IOV та розділення на графічному процесорі
SR-IOV (віртуалізація вводу/виводу з одним коренем) дозволяє представити один пристрій PCIe як кілька незалежних віртуальних функцій на різних віртуальних машинахЗастосовано до графічного процесора, це означає, що ви можете розділити карту на «частини» та призначити по одній кожній віртуальній машині з набагато більш прямим доступом, ніж повністю емульований графічний процесор.
Теоретично SR-IOV пропонує майже нативну продуктивність, але на практиці має нюанси: підтримка залежить від... конкретна модель графічного процесора, драйвер, гіпервізор та гостьова операційна системаЦе не повністю прозорий шар: віртуальні машини потребують специфічних драйверів, і існують обмеження на такі функції, як кодування відео, багатоекранний режим або певні 3D-розширення.
Наразі кінцевому користувачеві доступно дуже мало ноутбуків із SR-IOV за розумною ціною. Intel просуває цей підхід у вбудованих графічних процесорах Lunar Lake Xe2 та продуктах для центрів обробки даних (таких як Intel Data Center Flex), але Не всі їхні дискретні графічні процесори для настільних комп'ютерів надають користувачеві можливість використовувати SR-IOV.В AMD та NVIDIA підтримка SR-IOV та надійний спільний доступ до графічних процесорів здебільшого зарезервовані для дуже дорогих професійних лінійок (NVIDIA RTX vWS, серія A, деякі Radeon Pro з SR-IOV тощо), які також передбачають складне ліцензування та обмежену офіційну підтримку дистрибутивів, таких як Debian.
Віртуалізація програмної графіки (VirGL, драйвери virtio-gpu, RemoteFX тощо)
Найпоширенішим підходом у домашніх та лабораторних умовах залишається звернення до віртуальні графічні адаптери надані гіпервізором: virtio-gpu з VirGL у KVM, SVGA у VMware, синтетичні адаптери у Hyper-V тощо. Тут фізичний графічний процесор використовується спільно більш опосередковано, і значна частина роботи виконується у віртуальному драйвері та центральному процесорі.
З такою конфігурацією графічної продуктивності зазвичай достатньо для 2D-роботів, офісних програм та відео з помірною роздільною здатністю, але вона стає недостатньою для інших завдань. 4K, складна анімація, важкі вебсайти та вимогливий 3D-контентУвімкнення VirGL може погіршити ситуацію, якщо вбудований графічний процесор хоста має недостатню потужність або якщо конфігурація гостьової системи налаштована неправильно (недостатньо відеопам'яті, відсутні драйвери тощо).
Гіпервізорні середовища та їхній вплив на продуктивність графіки
Графічна поведінка віртуальної машини також сильно змінюється залежно від гіпервізора та інструментів інтеграції.
En KVM/QEMU з LinuxТипова комбінація для настільних комп'ютерів — virtio-gpu + VirGL, що підтримується драйверами Mesa у віртуальній машині. Це вимагає, щоб на гостьовій системі були правильно встановлені відповідні доповнення (spice-vdagent, драйвери virtio тощо), а на хості — функціональне 3D-прискорення на фізичному графічному процесорі. Зі скромним інтегрованим обладнанням, таким як Renoir iGPU, легко перевантажити відеопам'ять і зіткнутися з заїканням у роздільній здатності 4K.
En VMware vSphere, робоча станція або програвачВіртуалізація графіки дуже добре продумана для використання на робочих столах та у віртуальних диспетчерських системах (VDI). Відеодрайвер VMware у віртуальній машині та технології розвантаження мережі та сховища (VMXNet3, паравіртуальні драйвери) допомагають компенсувати деякі накладні витрати. Незважаючи на це, сама VMware визнає у своїх тестах процесора, оперативної пам'яті та диска, що існують... штрафи від 5 до 25% залежно від підсистемиУ графіці, чим складніше робоче навантаження, тим більший вплив.
En Hyper-VХоча більшість документації зосереджена на процесорі, пам'яті, мережі та сховищі, також підтримується прискорення за допомогою графічного процесора. розподіл дискретних пристроїв (скрізний доступ) та розподіл на графічний процесорMicrosoft дозволяє надавати доступ до графічного процесора або частини його ресурсів певним віртуальним машинам, але знову ж таки, це повністю залежить від базового обладнання та сумісності драйверів.
Процесор, оперативна пам'ять та диск: контекст, що визначає роботу графічного процесора
Перш ніж звинувачувати лише відеокарту, варто перевірити решту стеку віртуальної машини. Віртуальний або спільний графічний процесор працюватиме набагато гірше, якщо Процесор перевантажений, пам'яті недостатньо або сховище має занадто велику затримку.Відчуття графічного "затримки" насправді може бути вузьким місцем в іншому місці.
На рівні процесора гіпервізори, такі як ESXi або KVM, керують кожним віртуальним процесором (vCPU) як незалежним процесом, який може перебувати в станах RUN (виконується), WAIT (очікування вводу/виводу або простою), READY (очікування своєї черги, оскільки немає вільних фізичних ядер) або CSTP (співзуп, коли планувальник має синхронізувати vCPU багатоядерної віртуальної машини). Високі значення READY (>10%) або високий CSTP Вони є ознакою перевантаження процесора та призводять до поганої інтерактивності, що ви помітите в анімації миші та віртуального робочого столу.
Також потрібно контролювати нерівномірне використання ядер: багато настільних програм використовують лише один або кілька потоків. Якщо віртуальна машина має 8 віртуальних процесорів, але навантаження зосереджено на одному, додавання більшої кількості віртуальних ядер не має сенсу. Краще дати йому менше віртуального процесора, але вищу ефективну частоту. (наприклад, шляхом перенесення віртуальної машини на хост зі швидшими ядрами та налаштування політики живлення або використання індивідуальні термопрофілі щоб увімкнути режими Turbo Boost або AMD turbo).
Оперативна пам'ять – ще один критичний момент. Віртуальні машини «пожирають» пам'ять, особливо якщо гостьовий робочий стіл використовує важке графічне середовище, браузер з багатьма вкладками та програми для редагування. Якщо хост починає використовувати swap або віртуальна машина вмикає механізми розширення чи внутрішнього swappingu, Результатом є короткі паузи, які ви сприймете як графічні мікроелементи.
Нарешті, диск: хоча це може здаватися непрямим зв'язком з графічним процесором, повільне сховище призводить до того, що гостьовій системі потрібно більше часу для завантаження ресурсів, текстур, кешу браузера тощо. У тестах з fio та невеликими блоками (4K), Кількість операцій вводу-виводу в секунду віртуальної машини може зменшитися на 20-25%. Що стосується порожнього металу, це особливо помітно в рішеннях типу VMware зі спільним сховищем. Для настільних комп'ютерів це менш помітно, ніж для баз даних, але сукупний час очікування зрештою впливає на загальну продуктивність.
Віртуалізація проти голого металу: коли кожен варіант має сенс
З огляду на все вищесказане, чи варто продовжувати боротися з продуктивністю графіки у віртуальних машинах, чи краще налаштувати виділені фізичні машини для певних завдань? Це значною мірою залежить від типу програми.
Програми, які дуже чутливі до затримки або мають екстремальні графічні чи обчислювальні навантаження, такі як бази даних в оперативній пам'яті, такі як SAP HANA, професійний 3D-рендеринг, симуляція, високорівневий штучний інтелект або ігрові сервери реального часуВони продовжують працювати краще на фізичних серверах з прямим доступом до графічних процесорів, NVMe-дисків та центральних процесорів без значного перевищення передплати. У цих випадках навіть втрата продуктивності на 10-20% може означати меншу кількість підтримуваних користувачів або значно довший час обчислень.
Натомість, для Веб-сервіси, мікросервіси, стандартні бізнес-додатки, середовища розробки та офісна VDIВіртуалізація пропонує чудовий баланс між продуктивністю, гнучкістю та вартістю. Невеликі витрати на процесор, оперативну пам'ять та дискове навантаження компенсуються можливостями створення знімків, міграції в реальному часі, високою доступністю та централізованим керуванням.
У конкретній галузі графіки багато корпоративних розгортань віртуальних робочих столів використовують спільні графічні процесори професійного рівня (наприклад, NVIDIA з RTX vWS), щоб Десятки користувачів отримують безперебійний досвід роботи з легкими 2D/3D-додатками, відео та інструментами дизайнубез надання кожному користувачеві окремого фізичного графічного процесора. Ключ полягає в тому, щоб правильно розподілити обсяг відеопам'яті на користувача та не перевантажувати карту занадто великою кількістю віртуальних машин.
Як вимірювати та діагностувати продуктивність віртуальної машини
Якщо ви помітили, що віртуальна машина «повільна», перш ніж думати про зміну графічних процесорів, варто провести стрес-тести та переглянути показники. Інструменти, такі як sysbench для процесора, stress-ng або мемтестер для оперативної пам'яті, нитка для зберігання та iperf3 Для аналізу мережі вони допомагають кількісно визначити, наскільки гіпервізор вас штрафує.
На таких платформах, як vSphere, vCenter пропонує дуже детальні лічильники продуктивності: використання процесора у %, використання в МГц на віртуальний процесор, значення готовності та зупинки, час очікування, індикатори заміни тощо. ESXTOPЗ командного рядка ESXi ви можете бачити майже в режимі реального часу стан кожного віртуального процесора (vCPU), розподіл навантаження між фізичними та віртуальними ядрами, вплив Hyper-Threading та поведінку станів енергозбереження.
У Hyper-V, Hyper-V Manager та такі інструменти, як Windows Admin Center або PowerShell, пропонують схожі показники для процесора, динамічної пам'яті, дискового вводу-виводу, мережі та конфігурації NUMA. Знову ж таки, надмірно виділені віртуальні процесори, погана відповідність між топологіями vNUMA та pNUMA хоста або агресивне перевищення вимог до процесорів – все це потенційні проблеми. Поширені причини низької продуктивності, які помилково вважаються «графічними проблемами».
Що стосується самого графічного аспекту, практичний тест простий: відкрийте той самий складний веб-сайт або те саме відео YouTube на хості та у віртуальній машині з однаковою роздільною здатністю та спостерігайте за різницею у використанні процесора, споживанні оперативної пам'яті та температурі. Часто справжнім вузьким місцем є те, що Віртуальна машина виконує завдання за допомогою програмного забезпечення, яке завантажується на графічний процесор на хості..
Віртуалізація робочого столу: хитрощі, щоб отримати максимум від вашого графічного процесора, не витрачаючи цілого статку
Якщо ви працюєте на споживчому ПК або ноутбуці та хочете, щоб ваші віртуальні машини для робочого столу працювали якомога плавніше, не використовуючи дорогі SR-IOV або графічні процесори центрів обробки даних, існує кілька найкращих практик, які дуже допоможуть.
Перше, що потрібно зробити, це переконатися, що ваш процесор підтримує та має ввімкнені розширення віртуалізації обладнання (Intel VT-xo AMD-V) у BIOS/UEFI. Без цього гіпервізору доведеться емулювати більше програмних елементів, а витрати на продуктивність різко зростуть.
Під час створення віртуальної машини доцільно вибрати віртуальні диски фіксованого розміру замість динамічнихЗа умови, що у вас достатньо місця на SSD-накопичувачі. Динамічно зростаючі диски більш схильні до фрагментації та деградації вводу/виводу, що також призводить до уповільнення завантаження гостьової операційної системи та графічних програм.
Щодо сховища, по можливості розміщуйте віртуальні машини на диску. найшвидший, який у вас є, в ідеалі NVMe SSDЗапуск віртуальних машин з механічних жорстких дисків або повільних зовнішніх накопичувачів (USB 2.0, низькопродуктивні накопичувачі) – це вірний шлях до постійних зависань, зокрема у відділі графіки.
Не забудьте встановити засоби інтеграції з гіпервізора в кожній гостьовій системі: гостьові доповнення у VirtualBox, інструменти VMware у VMware, служби інтеграції у Hyper-V або пакети spice/virtio у KVM. Ці компоненти забезпечують оптимізовані драйвери для відео, миші, мережі та дисків, і є основою якісної графіки.
На рівні ресурсів це надає кожній віртуальній машині Ядра оперативної пам'яті та процесора, які ви можете реально використовуватиДля сучасного робочого столу Linux або Windows 4 ГБ оперативної пам'яті зазвичай є мінімально прийнятним обсягом для безперебійної роботи, а 2-4 добре завантажені віртуальні процесори цінніші, ніж 8 віртуальних процесорів, половина з яких не працює. І переконайтеся, що на хості не закінчується пам'ять: якщо хост-система почне використовувати swap, усі віртуальні машини постраждають від наслідків.
Нарешті, перевірте налаштування відео віртуальної машини: виділіть достатньо відеопам'яті, увімкніть будь-яке 2D/3D-прискорення, що пропонується вашим гіпервізором, і налаштуйте роздільну здатність на реалістичну для вашого обладнання. Робота з роздільною здатністю 4K всередині віртуальної машини зі скромним вбудованим графічним процесором вимагає забагато.Зменшення роздільної здатності до 1440p або 1080p часто радикально покращує плавність зображення без різкої втрати різкості.
Безпека, управління та висока доступність у віртуалізованих середовищах
Окрім продуктивності, не слід забувати, що сучасна віртуалізація включає багато технологій безпеки та управління, які також опосередковано впливають на графічний та загальний досвід роботи з віртуальними машинами.
Такі функції, як Безпечне завантаження Віртуальний TPM (vTPM) у Hyper-V та інших гіпервізорах дозволяє гостьовим системам використовувати той самий захист, що й сучасний фізичний ПК: підписане завантаження, BitLocker, вимоги Windows 11 тощо. Захищені віртуальні машини додають ще один рівень, запобігаючи легкому маніпулюванню вмістом віртуальної машини скомпрометованим хостом.
У сховищі такі формати, як VHDX Вони підтримують великі розміри, пропонують кращий захист від пошкоджень і включають такі функції, як диференційовані диски, спільні диски між віртуальними машинами та якість обслуговування IOPS для кожного віртуального диска. Все це призводить до покращеної стабільності та швидкості реагування віртуальних машин, коли кілька віртуальних машин використовують одне й те саме фізичне сховище.
В Інтернеті, використання розширені віртуальні комутатори, синтетичні адаптери, VLAN, SR-IOV на мережевих адаптерах, черги віртуальних машин (VMQ) та об'єднання мережевих адаптерів Це дозволяє зменшити навантаження на процесор під час інтенсивного трафіку та забезпечити підтримку хорошого рівня продуктивності віртуальних машин, що залежать від мережі (наприклад, віддалені робочі столи або потокова передача графічних програм).
Зрештою, такі функції, як Міграція віртуальних машин у реальному часі, міграція сховища та асинхронна реплікація між хостами Вони дозволяють підтримувати високу доступність без необхідності вимикати машини. Можливість переміщувати віртуальну машину в режимі реального часу з одного хоста на інший, непомітно для користувача, є однією з головних переваг порівняно з базовою системою, також для робочих навантажень з деякими вимогами до графіки.
З огляду на все це, очевидно, що максимізація графічної продуктивності в сучасних віртуальних машинах полягає не лише в купівлі найдорожчого графічного процесора чи сліпій довірі до SR-IOV. Йдеться про... Збалансуйте процесор, оперативну пам'ять, дисковий простір, мережу та графічний процесор; виберіть правильний гіпервізор; увімкніть відповідні технології віртуалізації та прискоренняІ, що дуже важливо, уникайте надмірного виділення ресурсів або недостатнього використання віртуальних машин. Коли всі ці елементи поєднуються, віртуальний робочий стіл може максимально нагадувати роботу фізичної системи, навіть на моніторах 4K, без необхідності інвестувати в обладнання центру обробки даних або надмірно дорогі професійні ліцензії.
