-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Running with --hostdisplay on TurboVNC with full Xfce desktop environment #1
Comments
An interesting question.
I am a bit surprised that you get no window manager. If there is none on the TurboVNC display, xfwm4 from the xfce image should do the job.
It should work. You could run x11docker with option
x11docker has an option |
Ok I ran it with the http://paste.ubuntu.com/26154553/ I also see this error on stdout right at the beginning. Does not seem to appear in the log file:
I use it for a real remote session. The host is a headless server, so I want everything running in the TurboVNC view. However, now as I am investigating GPU acceleration in docker a bit further, perhaps I need to use a base image that is Ubuntu 14.04 also, in order to have matching GPU libs in the docker image? Or maybe it's possible to get the matching libs into the x11docker playonlinux image too? Have to investigate this further. The host runs an i915 Intel GMA-based GPU. I have VirtualGL acceleration working fine with the TurboVNC display on the host right now at least. |
It seems the TurboVNC display misses a lot of important X extensions. For GPU acceleration, you need at least XRender and XComposite:
Is TurboVNC able to access an already running display? Than the solution would be to create a proper X display with x11docker that TurboVNC can send remotly. In the readme I show a possible VNC setup. Though, I am not familar with VNC in general:
The first step would be to get a working sample without GPU acceleration. If that works, we can have a deeper look at how to get the GPU running.
If you have open source drivers on your server, most probably it will work fine with the debian image.
If the image misses some driver libs, you can add them with a custom Dockerfile:
Early versions of x11docker used VirtualGL, too, to allow GPU acceleration with Xephyr. But I found that immediate GPU access was quite more performant with later added options --weston-xwayland, --xdummy-xwayland and --xorg. I will have a look at the xauth error; maybe TurboVNC does not provide an authentication cookie. x11docker should catch xauth errors and handle them. |
It should be possible to support GPU acceleration for 3D apps without those extensions though(?), as I've seen videos with this setup running 3D apps just fine. However for 3D we only require OpenGL. I guess the desktop environment requires more advanced X extensions. I don't really have a clue about those. I'm really surprised though, as I would have assumed someone must have tested TurboVNC on a modern desktop environment before. I've run the Ubuntu desktop on VNC before without problems (natively without docker). I found TigerVNC which seems to be able to attach to a native X display, and has a few more extensions, but with TigerVNC x11docker doesn't start at all: |
In the logfile I see some xauth/cookie errors. It seems I have to look deeper in this, maybe TigerVNC has no cookies, but x11docker does not recognize that and handles this wrong. You can try to use option You still try to run x11docker on the display provided by TigerVNC with option Side note: In your first logfile with TurboVNC there is another error message:
This indicates that the TurboVNC display has extension MIT-SHM enabled; short said, it enables some shared memory that docker containers normally cannot access. Avoid this error with option |
Ok thanks. I'll take a look at your suggestions. In the meantime I managed to get the native X running (X.Org X Server 1.15.1), and attached a TigerVNC viewer to that. However the result was the same as with TurboVNC (it works, but no window manager): |
Progress! Got the window manager working with TurboVNC and your suggestions:
The deciding switch was Still need to test out your other suggestions. |
:-) I just got a working local setup with TigerVNC:
Additionally using
Do you mean, with a host window manager using |
No I wasn't using that option. When I was running without the But I now figured out what was making the desktop slow. In the Xfce settings I disabled desktop composition, and that significantly sped up everything. I think VNC does not like compositing. It probably forces many more updates to be drawn, making everything sluggish. Disabling composition almost restores it to This is pretty cool now. Seems almost usable. Probably needs a bit more tweaking and tuning, but the important part is that it works :) Now I need to figure out what your |
Good to know, thanks for pointing that out!
It is not better or faster, it is just a simple invisible/headless X server like Xvfb, but using Xorg itself. It is not capable of GPU acceleration. The next step is to get GPU to work. Do I understand right that you can use your graphics card without a monitor being plugged in? Most older cards can't. If you can run a regular Xorg session (like with
|
Yep. This is the trick with VirtualGL. The GPU requests are forwarded from whatever display you're using (for example a VNC session on a virtual display), to the So yes, I am able to run a native desktop without any physical display being connected.
What does this do? I assume it runs Xorg on the host, and then forwards everything from the docker container to it? Or is it running Xorg in the container somehow instead? |
I am a bit confused. I thought, you would use the GPU of the headless server itself. Some new graphics cards allow that, while older ones need a real monitor to work. (Older ones can be fooled with a fake monitor, a cheap VGA plug with a few chips simulating a real monitor.)
If your headless server has a GPU and it works without a real monitor, a setup with |
Yeah sorry I wasn't clear. This is the way I was planning to use it. Headless using the host GPU. I just wasn't aware of TigerVNC and x0vncserver before, so I was using TurboVNC with VirtualGL instead (and TurboVNC/VirtualGL was then accessing Xorg on the host for GPU operations, but not for anything else). Now since TigerVNC allows direct attachment to the native Xorg through Only problem is I just stumbled on a bug in my current kernel that crashes the Intel GPU drivers when running any 3D apps...doh! So I need to update the kernel and reboot before I can proceed further. But this is a server with other people on it, so I'll have to do that later. In any case thanks a lot for your help! Once I get the updated kernel running I'll let you know how it went. |
Does the setup work with
Yeah, I am quite interested! Maybe TurboVNC allows attaching to existing X servers, too, I just did not find the possibility on the first glance. It seems to me that TurboVNC is better maintained than TigerVNC. The developer of TurboVNC is also the developer of VirtualGL. He was very kind when I asked some questions years ago. Oh, and an important note: You need option
|
Nope :-/ I'm stuck again.
I think I need to run X as root. Should I run x11docker with sudo? That seems kind of risky. |
Strange ... never had that error message before.
That is not risky, but would not help either :-D. x11docker runs X as non-privileged user even if it was started as root. From Xorg man page:
It may help to set XDG_DATA_HOME. Try |
Nope. Same error. Is there any way I could pre-run X as root myself, and let x11docker use that display instead of x11docker starting X itself? As I google about running X as non-root, I get pages upon pages of discussions, but could not find any real solution for it. It seems it is not a solved problem, as most people run X on the native display from the console, and it doesn't seem that it likes being run from a remote SSH session unless root. |
Easiest solution seems to let x11docker just |
Before some recent changes Xorg was always started as root and had the setuid bit set. Ubuntu 16.04 and debian 9 can restore this behaviour with package Do you have a file
That is already possible. You can run |
The Xwrapper.config file was present, but changing it didn't help. I'm able to run X as non-root manually though, so it's kind of strange x11docker isn't able to do it. |
I also get these warnings. Especially the first one is not correct. It thinks it's starting within X, but it's started from within an SSH session.
|
Do you run X with
x11docker checks the output of |
I run it with
|
I have uploaded a slightly changed x11docker here, please try out: https://raw.githubusercontent.com/mviereck/x11docker/experimental/x11docker If that works, you can try to undo your changes in Xwrapper.config and try again. Thanks for the tty-output ... now I don't know how to divide between an X and an SSH session. :rolleyes: |
Progress again :) It works! However we still have some issues:
|
:-)
ok, I'll remove that option from the code. I assume, you mean
You need option
LOL. Try if
|
Yes.
Spent 30 minutes fiddling with |
x11docker tries to set the Can you show me the output of A workaround with weston and Xwayland is possible, but that adds some overhead I would like to avoid. Plain X should work. However, I am not familar with headless graphics cards. A possible technical solution, a fake monitor with a set of resolutions: http://www.ebay.de/itm/Lindy-EDID-DDC-Emulator-Adapter-for-VGA-Displays-EDID-Leser-32101/282698297700?epid=1004725383&hash=item41d221b164:g:tWQAAOSwhvFZJm8z A workaround:
|
I'm running out of steam a bit for today. One question though, what's the difference between I think it's better I test the sizes just by manually running X. Don't need the x11docker complexity added for figuring out this resolution problem. I can't imagine it's not possible to get this setup to work without any other workarounds. If it can display 320x200 it must be able to display other resolutions too. Even |
See, I run
|
me too :)
It is rather small. x11docker sets some options to have a good match of settings and expectations, but you can set those X options manually. For example, X option
Yes.
That looks good! xrandr shows |
Yeah, that is a good question. I even tried it with But I think what we see here also is one of the reasons you may want to use VirtualGL after all; there's no boxing match with the headless Xorg needed. I think I may have to edit the dreaded |
I got this to work with disconnected real VGA port on my Laptop:
I can place this virtual display beside my real display and move my mouse in this invisible space, and the resolution appears in xrandr output. Looks promising. :) |
Yeah those do not work on my machine. VGA1 and VIRTUAL1 are both disconnected. It refuses to accept any new modelines. I think this is the place where we hit the wall. It seems for this trick I might need a VGA dongle after all. The GPU is running and accessible through VirtualGL, but I cannot figure out how to set any other resolutions. |
Ok. More progress. This is how to change the resolution directly:
That will change it to whatever I want instantly. However I have to restart x0vncserver each time, but I guess it's not such a big deal. More important is I was able to set the resolution to something sensible. This works on x11docker too. But, TigerVNC is not as fast as TurboVNC. Much more lag. I think it's because it's mirroring the real X display through x0vncserver. I also don't have a mouse cursor nor clipboard integration. Anyway, now the intel drivers are missing in the docker image. I run glxinfo and it says |
Good hit!
Maybe xrandr will accept modelines within your
The GPU of the headless server? Did you make the kernel upgrade?
Of course, yes. Without this option the docker container cannot access the GPU hardware.
Maybe TurboVNC will offer an option to access existing displays like TigerVNC does. |
I was thinking about this project this morning, and maybe the most VNC-friendly solution would be to run a VNC server inside the docker container. Not sure if that's in the spirit of x11docker, but I think that's the most appropriate and self-contained solution. Then there's no need to mess with xauth cookies or any other security implications. The only thing that is needed is for VirtualGL in the container to have access to the host GPU. So basically this would be your standard VNC + VirtualGL setup, except the server is running in the container. A setup like this was the reason VirtualGL was created in the first place. Running x11docker on But I think perhaps you didn't build x11docker for this purpose in mind, so don't want to force any new ideas on your project. I might have to figure out how to build my own container from scratch, in order to understand all the moving parts properly and get it set up as I want. I'm putting this project on hold for now. My "quick and easy" idea is turning into a full-time project otherwise..hehe. Just wanted some easy way to get Wine + VirtualGL working in a self-contained package, but turns out the "easy way" is learning three new technologies (Wine + VirtualGL + Docker) at the same time. Need more than a weekend for this. |
That is possible, of course. Example: https://stackoverflow.com/a/16311264
With 'host' you mean the VNC server or VNC client?
It would provide the best GPU performance. To run multiple container on display :0 and keep them isolated, option
Ok, the main purpose was with local access in mind. I am not experienced in network setups.
You have everything running now what you need ... if the xrandr part is to annoying, just use One note, a cool alternative to VNC is xpra. It also allows single applications instead of full desktop transfer and has good netwerk transfer rates. |
Thanks. Yeah this looks along the lines of what I was thinking.
Hehe..yes it was useful. At least I learned some new tricks :)
No I mean the docker container needs some way to access the GPU on the docker host, so that VirtualGL is able to run. At least I think this is the way it's supposed to work.
Seems this has dependencies on the host though(?). Which was something I wanted to minimize. I don't have that stuff on Ubuntu 14.04, as far as I know. Also it means yet another component to research and configure. The problem is the physical display is missing, so it makes setting up stuff like that harder. Most headless solutions all focus on VNC, so there's little support or docs for setting up anything else. Also the overwhelming performance hit will come from VNC itself and how it operates with the remote display, which I already noticed with x0vncserver vs vncserver, so it's probably better to focus on optimizing that part. VirtualGL vs native GPU through
Yeah xpra is pretty cool, but it's not so good with 3D stuff I think. TurboVNC on the other hand really seems focused on bringing decent remote 3D performance. I would test all these options out individually though, if I had some time to do it. Would be interesting to see and document the differences of all the solutions. |
if I remember right, VirtualGLis thought to allow GPU acceleration on computers without a GPU, for example using the GPU of client computers while the application is running on a headless server without GPU. Of course, using VirtualGL to forward your server GPU in docker container / VNC display is possible, too. I've used VirtualGL for docker containers years ago. If I remember right, my setup was:
Yes, it needs
x11docker would do the setup, it just needs this as dependencies.
Maybe the best current docu is this thread ;-).
You can run |
Yes it can be used in several setups. Both remote GPU and local GPUs are supported. With VNC its primary purpose is to provide GPU acceleration to virtual displays that would otherwise not support it. In most cases you will run vncserver on the same host as the GPU, but it's possible that everything is on separate computers (vncserver, GPU, client).
Ok, this is exactly what I need for running vncserver inside the docker container. I think this would give the simplest setup, only requiring docker on the headless host, and a VNC client on the remote computer. No other components are really required.
Ok can you explain what the advantage of this setup is? So Xwayland is sort of like a new version of Xorg? So this is like running |
Except try setting up xpra on Ubuntu 14.04. I tried it once and it was a complete nightmare. So I'm a bit reluctant to burn another 12 hours of my life up in smoke. That's why every time you bring up xpra I try to change the subject. Not a fan of touching that Python Spaghetti bolognese mix on 14.04 again. |
Yes, you may be right. x11docker would give more GPU performance; I found that VirtualGL is not as effective as direct GPU access, even on a local setup. But in a VNC setup, the network transfer lag is more important than GPU performance.
Wayland is the successor of Xorg and incompatible to Xorg's X11 protocol. Xwayland is an X server that can run in Wayland to support X11 further on. Weston is a reference implementation of the new Wayland protocol. x11docker can run the combination weston + Xwayland on Xorg. This causes some overhead (two layers above Xorg), but has some advantages:
Oh, ok. I only use xpra for local setups, don't know how hard it is to set up real network connections. But I want to note that xpra in Ubuntu trusty is very outdated and has been developed quite further. www.xpra.org has an Ubuntu repository.
I remember furthermore (and breaking isolation):
|
Ok. And can I attach a remote xpra client to the x11docker container somehow, without needing xpra support on the docker host?
Yes exactly. This was the conclusion I came to also, and that's where the nightmare started when I decided to upgrade to the latest version. Trusty is too old for the latest xpra, and you need to update a lot of components while trying to isolate the upgrades from breaking everything else on Trusty (mostly Python and all its dependencies, pip libraries + their dependencies..it all ends up in DLL hell, and you curling up in a corner begging for the torture to end).
Not hard at all. Getting an xpra client running on Windows (which happens to be my remote client in this case) is actually quite easy. The problem is I still have my doubts about remote 3D performance, but perhaps it's worth a shot if there are no docker host xpra requirements.
Ok thanks. |
You need xpra either on docker host or in docker image. To avoid DLL hell on Ubuntu trusty, you can install xpra in the docker image. A Dockerfile could look like:
Build with To avoid Possible setup:
On client: Maybe, for first tries, don't use x11docker, instead enable the second or third CMD in image, build again und run docker on server with If it does not work with hostname winecontainer, try |
I had "trusty" instead of "stretch" in Dockerfile sources, it is corrected now (confused host system vs. image system). If you are already trying out, please regard this change. |
Oh, and by the way: you can create a dummy VGA plug yourself: |
Not sure if you are still reading here ... just want to tell you that in x11docker version 3.9.1.4 your solution with To avoid messing around with DISPLAY and XAUTHORITY, you can disable XAUTHORITY cookies with |
I'm still here :) Thanks for your help and fixes. I stopped participating and gave up on the whole Wine setup in the end, because I discovered cloud computing has evolved to enable high-FPS remote displays. It was easier to rent a Windows cloud computer than mess with Wine in the end :-/ Everything works, and the latency is not too bad. My purpose was to do some light gaming, and this setup works pretty well now, And I got an 8 core 16G machine for only a few cents per hour. Not too bad. Beats my dusty Ubuntu server any day. |
ok, that is hard to beat ... :-D Thanks for your discovery of |
This may be a stupid question since it's the first time I'm using docker and x11docker, but is it possible for the docker image to run Xfce on the host display?
I'm using Ubuntu 14.04, and I'm running a TurboVNC session on this host.
I want to get x11docker/xfce-wine-playonlinux to run fully on this VNC display, including the Xfce window manager and desktop environment.
So I run it like this:
x11docker --desktop --hostdisplay x11docker/xfce-wine-playonlinux
This works, but I get no window manager. I can't drag and resize any windows, because there are no title bars or resize handles on them.
When I start x11docker it says:
I'm not running any wm on the TurboVNC display myself. It seems to imply it should work, but it doesn't seem to :-/
Is there any way to get this combo to run? My goal is to try and get 3D acceleration for Wine through the TurboVNC VirtualGL layer in the end. However first I need to get the desktop working somehow.
Thanks.
The text was updated successfully, but these errors were encountered: