Headless operation should be possible as long as the drivers are working correctly. The first thing I would check is the output of 'lspci'. That will tell you whether you can see the GPU inside of the Docker container. For instance, this is how my nVidia GPU appears in the lspci output:
02:00.0 VGA compatible controller: NVIDIA Corporation GK104GL [Quadro K5000] (rev a1) If you aren't seeing the GPU inside of the Docker container, then you're dead in the water until you can fix that issue. Unfortunately I have no advice regarding how to access a GPU from within a Docker container, as I wasn't even aware that that was possible. If and when you can see the GPU, then follow the instructions here: https://virtualgl.org/Documentation/HeadlessNV to create xorg.conf and enable it for headless operation. On 11/3/17 1:16 PM, Joscha Knobloch wrote: > Hey DRC, > > > thank you for your help. I think you are right. > > The Problem (i guess) is that i am running headless inside of docker. > > I don't have a xorg.conf yet but i also don't know what i should write > in there because i don't have a display connected to the machine. > > > The Nvidia-readme file is HUGE. > Can you tell me where i should take a look, to find out if i have access > to the GPU inside my container and what i need to setup to let VirtualGL > use the GPU? > > > > Best Regards > Joscha Knobloch > > ------------------------------------------------------------------------ > *Von:* [email protected] > <[email protected]> im Auftrag von DRC <[email protected]> > *Gesendet:* Freitag, 3. November 2017 17:31:05 > *An:* [email protected] > *Betreff:* Re: [VirtualGL-Users] Turbovnc and VirtualGL inside of a > nvidia-docker-container > > It sounds as if the 3D X server is not using the nVidia drivers. > > /opt/VirtualGL/bin/glxinfo -display :0 -c > > should show "NVIDIA Corporation" as the client and server GLX vendor, as > well as the OpenGL vendor. Double check /etc/X11/xorg.conf and make > sure that "Driver" is set to "nvidia" (in the "Device" section.) If > not, or if xorg.conf doesn't exist, then refer to nVidia's instructions > (/usr/share/doc/NVIDIA_GLX-1.0/README.txt) for more info on how to > configure it. If xorg.conf is configured properly, then check > /var/log/Xorg.0.log for any error messages from the nVidia driver that > may indicate why the GLX extension isn't being initialized. > > In short, this isn't a VirtualGL issue. It's a problem with the nVidia > driver configuration. Once that is working properly, VirtualGL should > work. In general, you should always verify that OpenGL is working > properly (and is accelerated) on the 3D X server before attempting to > use VirtualGL. > > > On 11/3/17 8:30 AM, Joscha Knobloch wrote: >> Hey, >> >> we need to run a Webbrowser inside of a Nvidia-docker container. >> Therefore GL is needed (or it is going to be very slow). >> >> The Solution with VirtualGL looks like it could work but I was not yet >> able to get GL-support inside of the docker-container. >> >> The newest Nvidia-driver is installed on the host-system. A "nvidia-smi" >> tells me the docker-container has also recognized the GPU and has the >> newest driver installed. >> Inside of the container I installed the mate-desktop-environment, >> virtualGL and Turbovnc. I can connect to the container via VNC and use >> it, but GL is missing. Typing "vglrun glxgears" returns: >> |Xlib: Extension "GLX" is mission on display ":0". Error: couldn't´t get >> a RGB, Double-buffered visual >> | >> "vglrun glxinfo" does kind of tell the same story besides printing the >> same message ~10 times. >> >> After finding your opengl-branch I build my setup on top of it, but I >> still can´t get it to work. >> >> Do I need to setup VirtualGl somehow? >> Do I maybe need to install Xvfb? (I read about that somewhere but I >> didn't´t understand why it was necessary and how it would be used.) >> >> I hope you can help me with this. >> >> Best Regards >> Joscha Knobloch > > -- > 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/5ce9d881-d595-09e9-6883-f96f1943ae49%40virtualgl.org. > For more options, visit https://groups.google.com/d/optout. > > -- > 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/virtualgl-users/5c2ffe6e46b3494686e19d24e15636f7%40brm.de > <https://groups.google.com/d/msgid/virtualgl-users/5c2ffe6e46b3494686e19d24e15636f7%40brm.de?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- 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/0f0c09b0-1e5f-618f-1a8c-0539c50721b2%40virtualgl.org. For more options, visit https://groups.google.com/d/optout.
