☰

Почему ssh меняет virgl OpenGL renderer обратно на llvmpipe software renderer? Могу ли я сохранить virgl в сеансе ssh?

tag-icon • tag-icon ssh qemu ubuntu-20.04 opengl x11-forwarding
Почему ssh меняет virgl OpenGL renderer обратно на llvmpipe software renderer? Могу ли я сохранить virgl в сеансе ssh?

Я создал виртуальную машину Qemu, и хост, и гостевая — Ubuntu 20.04. Затем я запускаю виртуальную машину Qemu с помощью команды

qemu-system-x86_64 ubuntu-desktop.qcow2 -m 2G -smp 2 -device virtio-vga-gl -display gtk,gl=on -nic user,hostfwd=tcp::5555-:22

Если я могу открыть рабочий стол гостевой Ubuntu и ввести в ее терминале

glxinfo -B

Вывод показывает мне, что OpenGL-рендерер — «virgl». Но если я подключаюсь по ssh к гостевой Ubuntu с -Xпараметром и ввожу glxinfo -B, вывод говорит, что OpenGL-рендерер — «llvmpipe (LLVM 13.0.0, 128 бит)», что является программным OpenGL-рендерером.

Итак, почему ssh меняет virgl OpenGL renderer обратно на llvmpipe software renderer? Есть ли способ сохранить оригинальный "virgl" OpenGL renderer в ssh session, как я вижу в окне Qemu?

решение1

Вывод показывает мне, что OpenGL-рендерер - "virgl". Но если я подключаюсь по ssh к гостевой Ubuntu с опцией -X и ввожу glxinfo -B, вывод говорит, что OpenGL-рендерер - "llvmpipe (LLVM 13.0.0, 128 бит)", что является программным OpenGL-рендерером.

Итак, почему ssh меняет virgl OpenGL renderer обратно на llvmpipe software renderer? Есть ли способ сохранить оригинальный "virgl" OpenGL renderer в ssh session, как я вижу в окне Qemu?

Поскольку -Xопция заставляет glxinfo общаться схозяинX-сервер, а не гостевой. Поскольку GLX — это «GL поверх X11», это означает, что glxinfo покажет возможности, доступные из Xorg хоста — ограниченные тем фактом, что он общаетсяпо сети,следовательно, нет прямого доступа SHM или DRI. (Например, современные программы X11 во многом полагаются на возможность прямого обмена растровыми изображениями с X-сервером через MIT-SHM.)

Если вы хотите использовать гостевой X-сервер,не используйте -Xни-Yно вместо этого определите DISPLAY(и, возможно, также XAUTHORITY) указание на X-сервер, уже работающий внутри гостя.

(Чаще всего это display :0, но путь Xauth может измениться, поэтому вам действительно следует проверить значения DISPLAY и XAUTHORITY через «локальный» терминал в гостевой системе. В последних версиях вы также можете найти эту информацию в systemctl --user show-environment– это надежный источник.)

Но если вы хотите использовать виртуальный графический процессор гостя, продолжая при этом отображать окна X на хосте через SSH, я подозреваю, что вы не сможете использовать GLX, но вам может понадобиться программное обеспечение на основе EGL (проверьте, может ли оно eglinfoполучить доступ к графическому процессору virgl).

В качестве альтернативы можно запустить приложения на гостевой ОС, но управлять ими через VNC (x0vncserver) или через протокол удаленного взаимодействия SPICE Qemu (который можно использовать через сеть, как VNC/RDP).

Связанный контент