Как стать автором
Обновить

Удалённый доступ к графике в Linux: от X11 до Docker с GPU

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров10K
Всего голосов 18: ↑18 и ↓0+23
Комментарии38

Комментарии 38

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

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

Для начала контейнер надо будет приготовить вручную под каждую задачу и под каждый Descktop/VDI. Т.к. у каждого потребителя графика нужна под свои задачи. Кому-то Blender. Кому-то Firefox, или Chrome нужной версии, с ворохом именно "вот таких вот" плагинов. С пробросом звука может быть отдельная эпопея.
Потом еще на все натянуть автоматизацию пересборки всех контейнеров при выходе очередных патчей безопасности в тех же браузерах.
А если попытаетесь запихнуть "все и сразу" в один контейнер, то сможете сильно удивится от его размеров.
В бытность развертывания терминальных серверов Windows, индивидуальная "подстройка" рабочих столов, занимала 80% времени от внедрения самого терминального сервера. А если ее не делать, то только ресурсов каждый терминальный клиент выедал в 2-3 раза больше, чем с оптимизацией.

Лично у меня, после всех этих махинаций Firefox почему-то все равно тупит. Пытался менять разные настройки - увы, не помогает.

Может кто сталкивался с подобными ситуациями ?

А его настройки и изменения пишутся в ~/rdesktop-data/config?
Проблем со скоростью чтения и записи нет?

X11 Forwarding: начинаем с простого

И развлекаемся с настройками X11 клиента (шрифты и прочее), скажем, на лаптопе с виндой. vnc явно проще.

А если клиент это тоже линуксовая машина с X11, либо Wayland?
Да и если кому-то понадобился так срочно проброс видео, что он делает его через проброс иксов, мне кажется, что качество шрифтов вряд ли будет беспокоить.

Уж vnc клиент есть подо всё что движется )

если кому-то понадобился так срочно проброс видео

Мне обычно нужен десктоп целиком.

Уж vnc клиент есть подо всё что движется )

Соглашусь, но настраивать его всё таки дольше, чем 1 команду для проброса иксов. Как передаёт автор этого поста, до того как он решил прибегнуть к готовым контейнерам, он собирался сначался на хостовый сервер сам установить VNC. Но цитируя его «Уж вроде бы наконец-то подключился через Remmina, но на выходе тупо чёрный экран. Проклял всё и пошёл искать готовые контейнеры.».

Мне обычно нужен десктоп целиком.

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

настраивать его всё таки дольше, чем 1 команду

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

apt install x11vnc
x11vnc -display :0

В вашем случае надо ставить докер, к нему примочку от NVidia/AMD/Intel, кастомный конфиг контейнера прописать, запустить... Явно больше 2х команд, не считаете? (Естественно, речь о голой/домашней системе, а не о сервере, на котором уже крутится докер с кучей контейнеров)

Интересная статья, а можно поподробнее про настройку звука в таком контейнере? У меня была проблема с pulseaudio когда пытался сделать нечто подобное.

SSH умеет сжимать трафик, что иногда помогает на медленных каналах связи.

Не думаю, что это поможет с RDP, c X11 да, существенно помогает, а в RDP же и так все сжимается, причем как раз алгоритмами под графику, а не zlib.

Использую kvm + spice - результат отличный, можно работать без лагов, даже видео пролетает на ура. Собственно, уже года два на такой схеме сижу, это офигенно. Минус - дай по видяхе на виртуалку, или ставь теслу которая в системе определяется как несколько карт. Еще есть гриды, но там подписка на дрова (да-да, так бывает) миллиард золотом в секунду, потому вариант отпадает.

VNC тормозит, лаги прямо сильно заметны. RDP хорошо работает на винде, на линуксе так себе, присутствуют глюки и нестабильность.

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

Правда адекватного варианта работы с видеокартой нет.

А у вас под рукой нет адекватного современного сравнения RDP и spice под Windows и Linux соответственно на медленных каналах?
Задумываемся начать перевод клиентов со старого RDP Windows на Терминальную систему под Linux. Но пять лет назад очень огорчило тестирование на каналах в 1-2Мбит. Терминальный сервер Windows работал вполне приемлемо. А вот Linux с RDP, в роли терминального сервера, был неприемлем для офисной работы. При этом клиенты Remmina вполне сносно работали с Windows терминальным сервером.

Интересная тема, а не подскажете пожалуйста, какую методологию использовали для замеров в тестах?

Чисто визуально или условно замеряли секундомером/как-то программно сколько занимает время на отклик, на рендер каких-то объектов, сколько пакетов и какого веса идёт по канал через Wireshark?

К сожалению, чисто визуально. Ставили два ПК рядом.
Но гоняли с неделю. Пока подопытные пользователи не взвыли.
Простая офисная работа. Открытие окон браузера с локальной почтой. Офисные документы. Да тонкий клиент 1С. Никакого видео и даже анимации в работе у пользователей не предусмотрено.
На родном RDP все происходит четче и плавнее. Особенно было заметно при попытке прокрутки офисных документов и в 1С.
Скорость канала была 2Мбит/с.

Пробовал через сотовую связь (LTE-модем в ноуте) - и то, и то визуально работает одинаково. Правда, spice не любит обрывы связи - подвисает и выпадает, когда как у RDP есть адекватное переподключение.

А RDP сервер был Windows или Linux?

Попробуйте x2go. Есть аналог RemoteApp, есть проброс звука, есть проброс принтеров, в версии от РедОС есть проброс смарт-карт. Только очень внимательно отнеситесь к безопасности, т.к. всё построено на ssh-туннелях. По производительности вроде неплохо, на старте сессии притормаживает, потом отлично работает (это для тестов следует учесть).

Подскажите пожалуйста, а как в этой схеме можно организовать автоматическое переподключение если связь с сервером пропала? В Remmina вроде нет встроенных средств для этого.

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

Во многом это заслуга RDP протокола, который гораздо эффективнее X11 forwarding в плане передачи графики по сети.

Слона то Вы и не заметили, X11 на вашем терминале это сервер, а RDP клиент. В случае с X11 вы можете с приложениями на разных хостах работать, в этом его сила.

Спасибо за замечание! Учтём!
Для нас в силу специфики проброс графики тема не специфичная, наша задача железо больше продавать, а не разворачивать на нём инфру, с VDI конкретно вовсе крайне редко взаимодействовали, так как всё обычно и так под рукой.

Для справки следовало бы указать, что в клауд гейминге используется исключительно WebRTC, и описать захват кадров из X11 доступными способами для передачи в любой поток.

Ожидал рабочий вариант с Wayland.

С Wayland по идее RDP ещё стабильнее должен работать, но готовых к работе контейнеров не находили. В следующий раз можем отдельно на локальной машине эту тему покрыть.

wayvnc у меня работает на swaywm. но он только для wlroots-based композиторов

но он только для wlroots-based композиторов

Вот эту вещь (безотносительно темы статьи) в Wayland вообще не понимаю. В иксах иногда тоже бывают проблемы какого-нибудь софта с конкретным window manager - но это скорее баги, в целом можно выбирать любой по вкусу. А тут бывают принципиально разные композиторы...

Это к сожалению, вся суть Wayland.
Вместо централизация и стандартизации большая часть всего функционала доступного в иксах они отдают на индивидуальную реализацию для тех кто занимается оконными менеджерами, окружениями рабочего стола.
Самое шизофреничное на мой взгляд это весь этот бред про заботу о безопасности из-за чего они выпилили нормальную поддержку глобальных комбинаций клавиш с жестами. И у KDE своя реализация, жёстко вшитая в исходники без нормального API для стороннего взаимодействия, у GNOME своя и т.д.

Подскажите плиз , я в Linux новичок , никак не могу победить какой то баг в Ubuntu 24.04 ... когда перевожу комп в ждущий/спящий режим .. Гаснет монитор , системный блок продолжает работать , клавиатура и мышь не отвечают .. только перегруз и соответственно потеря всего что делал... В настройках все "блокировки" выключены .. "Отключение монитора при бездействии" стоит на 12 минут , но с этим он работает нормуль . Подозреваю что-то связанное с драйверами видео ..

Помню , что в Windows по всем подключенным устройствам можно было запретить пробуждение по электропитанию ..

Не совсем наша тема, а подскажите, какое у вас окружение рабочего стола, какая видеокарта, драйвер проприетарный или открытый?

Повторяется ли эта проблема в других дистрибутивах, не пробовали что-то ещё ставить? Мы всем обычно для домашнего использования EndeavoursOS с KDE Plasma советуем.
https://endeavouros.com/

"Ждущий режим" и "спящий режим" - это, мягко говоря, слегка разное. Несколько лет назад в Ubuntu, мне помнится, были проблемы с гибернацией (т.е. "спящим режимом") - система некорректно его отрабатывала и, чтобы вернуть компьютер к работе, приходилось его жестко перезагружать. Не знаю, с тех пор починили этот баг или нет (я недавно пробовал по одному из гайдов включить таки гибернацию на своем ноуте с Минт - так и не завелось, а разбираться мне, честно говоря, было лень), но попробуйте отключить гибернацию и\или использовать только ждущий режим.

Гибернацию надо отдельно настраивать на Ubuntu 20-24. И она имела особенности с некоторыми драйверами видео.

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

Gstreamer захватывал экран и h264/265 кодеком сжимал данные. Проброс клавиатуры и мыши сделал на xcb.

Работало следующим образом. Заходил на удаленный компьютер по ssh и запускал там свою утилиту. Со своей стороны аналогичного клиента.

Из плюсов - в локальной сети можно было даже в шутеры играть (сам удивился). Из минусов - при работе с текстом иногда проскакивали кадры с артефактами.

Думал даже опубликовать исходные коды, но забросил проект.

ШаломЪ православные!
С GPU и spice сейчас в proxmox из коробки вроде работает. Но в моих серверах нигде GPU нет.
Находил вот такую полезную ссылку о том как добиться от XRDP скорости без GPU, но не пробовал:
https://gist.github.com/Nexarian/df58c572d4e8549ad57195093d7cad82
Если кто пробовал - напишите, пожалуйста.

Будет интересно почитать про проброс звука, особенно микрофона. Сейчас использую на виртуалке с win10 её встроенный rdp, клиент- xfreerdp на 12 дебиане. Пробовал и remina, но в ней нет или не нашел режима полного захвата клавиатуры, включая все клавиши-модификаторы. Микрофон ни там ни там не работает, хотя звук с сервера воспроизводится нормально. DE- mate, звук pipewire, всё ставилось из реп дебиана

Зарегистрируйтесь на Хабре, чтобы оставить комментарий