Ubuntu – Video driver under lxc container

12.04chrootgraphicslxcvirtualization

Since LXC (Linux Containers) is a kernel level super-chroot, I've been wondering what sort of video driver the containers have:

My host is Ubuntu 12.04 64-bit machine with ATI gpu. Will the LXC container have access to the same driver? Or do they need to be installed on each container?

Best Answer

Please, take a look at this script to create a LXC container that runs steam with sound and video acceleration:

http://bazaar.launchpad.net/~ubuntu-lxc/lxc/steam-lxc/view/head:/steam-lxc

The magic comes here:

Outside LXC:

    # Add the bind mounts to the container's fstab
    self.container.set_config_item("lxc.mount.entry",
                                   "/tmp/.X11-unix tmp/.X11-unix "
                                   "none bind,ro")
    self.container.set_config_item("lxc.mount.entry",
                                   "/dev/dri dev/dri none bind,ro")
    self.container.set_config_item("lxc.mount.entry",
                                   "%s/pulse.socket home/%s/.pulse_socket "
                                   "none bind,ro" % (self.config_path,
                                                     self.user.pw_name))

We export X11 with a bind mount the /tmp/.X11-unix directory to allow container to use host X11. Do the same with /dev/dri directory and audio socket.

Inside LXC:

    # Get pulseaudio to listen on the socket
    with self.user_privileges():
        subprocess.call(['pactl', 'load-module',
                        'module-native-protocol-unix',
                        'socket=%s' % self.pulse_socket,
                        'auth-cookie-enabled=0'])

    # Start steam
    self.run_command(
        ["steam"], {'DISPLAY': os.environ['DISPLAY'],
                    'PULSE_SERVER': "/home/%s/.pulse_socket" %
                                    self.user.pw_name})

Uses pactl to use a unix socket to communicate with host pulse audio server and later export the socket and DISPLAY environment variable to allow steam to use local X11 server and socket to audio server.

Take a look at the script and enjoy it :)

With that environment variables inside LXC you could play (theoretically) almost all games.

Best regards!

Related Solutions

Ubuntu – Public IP Address for LXC container

My approach assumes that your server has a single NIC, and you need to share that NIC between the host and the LXC guests. This involves using a bridge. The bridge owns and manages eth0. The host now configures its own networking on br0 instead of eth0. The LXC guests are configured to connect to the bridge.

On the host, sudo apt-get install bridge-utils.
On the host, replace eth0 with a bridge:

This is dangerous. Get this wrong and you could be locked out of your server. Be sure to have a local login enabled and that local console access works, so that you can revert this change if you have any problems.

In /etc/network/interfaces:
1. Replace auto eth0 with auto br0.
2. Replace:
```
iface eth0 inet dhcp
```
  with:
```
iface br0 inet dhcp
    bridge_ports eth0
```
  If you had a static network configuration, then you'd replace:
```
iface eth0 inet static
    address ...
    netmask ...
    gateway ...
    etc.
```
  with:
```
iface br0 inet static
    bridge_ports eth0
    address ...
    netmask ...
    gateway ...
    etc.
```
  You're just changing eth0 for br0 and adding the bridge_ports eth0 line.
3. Reboot the host. If you were doing this locally, then running sudo ifdown eth0 before you started, and sudo ifup br0 afterwards would also do. Note that the bridge can take a little time to come up, so give it five minutes after reboot before you assume that all is lost.
To move a given named LXC container over to a public IP:
1. Stop the container.
2. On the host, edit /var/lib/lxc/container_name/config and change lxc.network.link to br0.
3. On the host, edit /var/lib/lxc/container_name/rootfs/etc/network/interfaces and configure your public IP as you would normally (DHCP or a static configuration as needed). Note that the interface is still called eth0 from the point of view of the container.
4. Restart the container.
To change the default for new LXC containers, edit /etc/lxc/default.conf on the host and change lxc.network.link to br0.
If you don't need the LXC-provided NAT bridge at all (ie. all your containers will use the new bridge instead), then on the host edit /etc/default/lxc and change USE_LXC_BRIDGE to "false", and then on the host run sudo service lxc restart.

Ubuntu – lxc containers security borderlines

As I have seen about LXC It stores container information and (with the default backing store) root filesystems under /var/lib/lxc. Container creation templates also tend to store cached distribution information under /var/cache/lxc.

So Generally access to root filesystem only allowed to admin unless there is a misusage or wrong configuration user profiles while creating them.

But Ubuntu Developers may already came to this point and they have provided a secure solution with the help of AppArmor.

LXC ships with an Apparmor profile intended to protect the host from accidental misuses of privilege inside the container. For instance, the container will not be able to write to /proc/sysrq-trigger or to most /sys files.

The usr.bin.lxc-start profile is entered by running lxc-start. This profile mainly prevents lxc-start from mounting new filesystems outside of the container's root filesystem. Before executing the container's init, LXC requests a switch to the container's profile. By default, this profile is the lxc-container-default policy which is defined in /etc/apparmor.d/lxc/lxc-default. This profile prevents the container from accessing many dangerous paths, and from mounting most filesystems.

If you find that lxc-start is failing due to a legitimate access which is being denied by its Apparmor policy, you can disable the lxc-start profile by doing:

sudo apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start
sudo ln -s /etc/apparmor.d/usr.bin.lxc-start /etc/apparmor.d/disabled/

This will make lxc-start run unconfined, but continue to confine the container itself. If you also wish to disable confinement of the container, then in addition to disabling the usr.bin.lxc-start profile, you must add:

lxc.aa_profile = unconfined

to the container's configuration file. If you wish to run a container in a custom profile, you can create a new profile under /etc/apparmor.d/lxc/. Its name must start with lxc- in order for lxc-start to be allowed to transition to that profile. After creating the policy, load it using:

sudo apparmor_parser -r /etc/apparmor.d/lxc-containers

The profile will automatically be loaded after a reboot, because it is sourced by the file /etc/apparmor.d/lxc-containers. Finally, to make container CN use this new lxc-CN-profile, add the following line to its configuration file:

lxc.aa_profile = lxc-CN-profile

lxc-execute does not enter an Apparmor profile, but the container it spawns will be confined.