
Creé una VM Qemu, siendo tanto el host como el invitado Ubuntu 20.04. Luego inicio Qemu VM usando el comando
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
Si puedo abrir el escritorio del Ubuntu invitado y escribir en su terminal
glxinfo -B
El resultado me muestra que el renderizador OpenGL es "virgl". Pero si ingreso al Ubuntu invitado con -X
la opción y el tipo glxinfo -B
, el resultado dice que el renderizador OpenGL es "llvmpipe (LLVM 13.0.0, 128 bits)", que es un renderizador OpenGL por software.
Entonces, ¿por qué ssh cambia el renderizador virgl OpenGL nuevamente al renderizador de software llvmpipe? ¿Hay alguna forma de mantener el renderizador OpenGL "virgl" original en la sesión ssh como veo en la ventana de Qemu?
Respuesta1
El resultado me muestra que el renderizador OpenGL es "virgl". Pero si ingreso al Ubuntu invitado con la opción -X y escribo glxinfo -B, el resultado dice que el renderizador OpenGL es "llvmpipe (LLVM 13.0.0, 128 bits)", que es un renderizador OpenGL por software.
Entonces, ¿por qué ssh cambia el renderizador virgl OpenGL nuevamente al renderizador de software llvmpipe? ¿Hay alguna forma de mantener el renderizador OpenGL "virgl" original en la sesión ssh como veo en la ventana de Qemu?
Porque la -X
opción hace que glxinfo hable con elHospedadoresServidor X, no el del invitado. Como GLX es "GL sobre X11", esto significa que glxinfo mostrará las capacidades disponibles en el Xorg del host, limitadas por el hecho de que se está comunicando.a través de la red,por lo tanto, no hay acceso directo a SHM o DRI. (Por ejemplo, los programas X11 modernos dependen en gran medida de poder intercambiar mapas de bits directamente con el servidor X a través de MIT-SHM).
Si desea utilizar el servidor X del invitado,no usar -X
ni-Y
sino que en su lugar defina DISPLAY
(y posiblemente también XAUTHORITY
) que apunte al servidor X que ya se está ejecutando dentro del invitado.
(La mayoría de las veces es display :0, pero la ruta Xauth puede cambiar, por lo que realmente debería verificar los valores DISPLAY y XAUTHORITY a través de una terminal "local" dentro del invitado. En versiones recientes también puede encontrar esta información en systemctl --user show-environment
; esa es una información confiable fuente.)
Pero si desea utilizar la GPU virtual del invitado mientras sigue mostrando ventanas X en el host a través de SSH, sospecho que es posible que no pueda usar GLX pero que necesite un software basado en EGL (ver si eglinfo
puede acceder a la GPU virgl).
Alternativamente, ejecute las aplicaciones en el invitado, pero contrólelas a través de VNC (x0vncserver) o mediante el protocolo de comunicación remota SPICE de Qemu (que se puede utilizar a través de la red como VNC/RDP).