Running graphics-accelerated GUI apps in LXD containers on a Ubuntu desktop

https://blog.simos.info/how-to-easily-run-graphics-accelerated-gui-apps-in-lxd-containers-on-your-ubuntu-desktop/

by simosx • 8 years ago

81 20 8 years ago

blog.simos.info

mkesper• 8 years ago

You might also try vagrant-lxc (https://github.com/fgrehm/vagrant-lxc/blob/master/README.md). Can give you some ruby dependency hell, though.

pwnna• 8 years ago

Another alternative is lxdock (https://github.com/lxdock/lxdock), which uses LXD directly without dependency issues. The X11 support similar to what's done on this post is in a PR that I wrote.

enteroo• 8 years ago

Anyone managed to get this to work?

bmullan3• 8 years ago

I just did and it worked great !

Super easy as using the custom "profle" meant I really had to do nothing other than the single cmd to create the LXD container.. which took 15-20 seconds to create.

asfdsfggtfd3• 8 years ago

How secure is this (when also running the GUI using Xephr)? Compared to say running Virtual Box VMs or Quebes or LXD virtual machines?

EDITED in response to a comment.

simosx7• 8 years ago

This is a convenience tool, that uses your existing X11 session. You would not use it when testing malicious programs because they would be able to attack the X11 session (but not your host's filesystem).

If you want to test programs that might be malicious, then you would set up a separate X11 server like Xephyr and get the output to get directed over there. In that way, both the filesystem and X11 session would be separate from those of your host.

I mention the use of Xephyr in the Conclusions of the post. There is some new functionality in LXD that is being released soon that will make it very easy to use Xephyr as well.

asfdsfggtfd3• 8 years ago

I'm going to edit my original question in light of this comment.

simosx7• 8 years ago

Answering the updated question regarding the security of running what is described in the post, but using Xephyr and not the desktop's existing X11 session.

It is as secure as the individual components, that is whether there are security vulnerabilities in LXD, and in Xephyr. There are currently no pending security vulnerabilities to fix in either (as far as I know).

Of course, the same goes with VirtualBox. It is as secure as there are no pending known security vulnerabilities (https://www.techrepublic.com/article/10-new-vm-escape-vulner...).

asfdsfggtfd3• 8 years ago

So including Xephyr this is a reasonable way to sandbox a browser? To the same level of reasonable as browsing in any virtual machine is.

Is this sort of thing possible with Wayland? If so does Wayland already enforce the necessary process isolation or does something like Xephr for Wayland need to be developed first?

bmullan3• 8 years ago

This all uses only "unprivileged" containers NOT "privileged" container.. so "root" in the container is NOT "root" in the Host!

simosx7• 8 years ago

As a sidenote, Chrome OS uses LXD in a similar way to run Linux GUI applications like the terminal application they showed in Google I/O 2018.

Here is an article on how they do it, https://blog.simos.info/a-closer-look-at-chrome-os-using-lxd...

bmullan3• 8 years ago

Simos I just tried this on Ubuntu 18.04 and it worked great!!

Started Firefox in an LXD container created w your customized "profile" went to YouTube a was playing music videos great... All from the LXD container.

Really great work making this so easy now.

simosx7• 8 years ago

Thanks!

shmerl3• 8 years ago

Can be useful for running older games that don't work on modern distros anymore.

I didn't quite get why snap is needed in the above case. Doesn't lxd itself already offer sandboxing?

For Wine, something like snap / flatpak can be useful to get that sandboxing without running a full blown container.

simosx7• 8 years ago

There are two steps to set up your LXD installation in order to create GUI containers.

If you are using the snap package of LXD, you only need to perform the second step.

If you are using the deb package of LXD, you need to perform both steps.

A snap package of LXD is not required to setup GUI containers, it just makes it a bit simpler (one step instead of two).

If there is some Windows application that is really useful to have on Linux, then it makes sense to invest the effort to create a snap package. The snap package will be usable to everyone. There are already Windows games that have been packaged as snaps, and the process could be replicated with some effort (example: https://github.com/snapcrafters/tmnationsforever).

The GUI container instead, is helpful if there is an application that you would like to run but cannot invest the effort to package it as a snap.

shmerl3• 8 years ago

Snap / Flatpak help with providing Wine configuration, but you can't pre-package stuff that's not open source for instance.

For example you buy some game on GOG, then something like pre-configured Snap / Flatpak or PlayOnLinux / Lutris scripts can help automating configuration but you still need to provide the installer to them first.

One problem that I personally encountered with that approach is that someone has to maintain those scripts. They tend to become obsolete, since Wine is changing and things are moving forward, while the amount of such games is potentially quite huge and there are not enough maintainers to update them all.

In the end it's just easier to install stuff yourself in a new prefix. Sandboxing though is a neat feature which you can use even without relying on such pre-made scripts.

indigodaddy• 8 years ago

BTW, +1 for Simos' blog, especially his series of Ubuntu+LXD+HAProxy (with SSL termination and host based ACLs) +ZFS, etc, etc. All really good stuff, easy to follow and setup, and IMO, even though over the years LXC has lost some of its gluster to Docker, the combination of LXD/HAProxy is actually a simpler and superior way method in a lot of use cases than Docker, et al.

Running graphics-accelerated GUI apps in LXD containers on a Ubuntu desktop

Related Stories