On 8/20/18 6:09 AM, romangrothausmann wrote: > Removing the vglserver config > (https://gitlab.com/romangrothausmann/dfitksnap/commit/4df27e3dfeba40dfabbd8989af0c80a8ecb8bf0b) > works, > and using vgl_xauth_key instead of VGL_DISPLAY=:0 > (https://gitlab.com/romangrothausmann/dfitksnap/commit/14207f23c29ea7ace9eb086b5471d02cc232532d) > works as well. > However, if I share ~/.Xauthority (rw) with a prior 'xauth merge > /etc/opt/VirtualGL/vgl_xauth_key' > both VNC and VGL-X are not accessible > (https://gitlab.com/romangrothausmann/dfitksnap/commit/5dfa12f1e5669376137ff2c6b57b5a64170eb29f). > > To my understanding that originates from the missing "sed -e > 's/^..../ffff/'", > whose documentation I could not find but which to my understanding removes > the binding to the host name (which is different in the docker container). > > This could also be the problem I am facing when running run.sh from a > vglconnect terminal, > where $DISPLAY is something like localhost:N.n which does not make sense > within the > docker environment. However, just stripping localhost from DISPLAY did > not make it work either.
In a remote SSH environment with X11 forwarding enabled, localhost:N.n is the server-side endpoint of the forwarded X11 connection. localhost:N.n is a TCP listener, which is why simply stripping "localhost" from DISPLAY didn't work (removing the hostname causes Xlib to attempt to make the connection with a Unix domain socket rather than TCP.) By default, SSH will not allow connections to the endpoint except through the loopback (127.0.0.1) interface, so Docker wouldn't be able to connect to the endpoint by default. You could set "X11UseLocalhost no" in sshd_config, thus allowing connections to the endpoint from anywhere, but there are security ramifications to this. It sounds like what you really need is the Unix domain socket forwarding feature in OpenSSH 6.7 and later, although I have no idea how to set that up to accommodate X11 forwarding. > Hm, is that so or is their config line just unnecessary as well? > If I understand the post > https://medium.com/@pigiuz/hw-accelerated-gui-apps-on-docker-7fd424fe813e > correctly, it is run on a remote (AWS G2 instance) that is running a VGL > X, as setup by > https://github.com/plumbee/nvidia-hw-accelerated-box/blob/master/root_setup.sh#L140 > which (installs docker on the host for other use but) is not running in > a docker container. > Or in another way round, https://github.com/plumbee/nvidia-virtualgl > would be lacking the > command that starts the VGL X-server within the container prior to > running any program with vglrun. That was just my first impression. I wouldn't be able to say for sure without attempting to bring up their container. > This made me wonder if it is possible to create a docker image that would > allow a contained app to use 3D acc. from the host even for non-NVIDIA > graphics-cards such as amd-radeon avoiding nvidia-docker. > However, if I remove "--runtime=nvidia" from my docker run command the > GL context seems to be gone: > QGLTempContext: No GL capable X visuals available. > QGLContext::makeCurrent(): Cannot make invalid context current. > Any idea of how to realize this scenario? > Do I need any changes in the dockerfile to make this work? I don't think you could make this work without specific support from the GPU vendor. My understanding is that the nvidia-docker stuff sets up an OpenGL stack within the Docker container that allows OpenGL commands to be passed from guest to host. Doing that in a performant way requires hooking into the stack at the driver level, which isn't something that can be done generically. -- You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/16741b07-d670-5cf3-59bc-7d098c35554a%40virtualgl.org. For more options, visit https://groups.google.com/d/optout.
