Running Containerized GUIs on LXC with Pantavisor Linux
Tags: lxc, containers, gui
Published: 2021-09-22 01:06:26

---
title: Running Containerized GUIs on LXC with Pantavisor Linux
published: true
date: 2021-09-12 23:26:43 UTC
tags: lxc,containers,gui
canonical_url: 
---

![](https://cdn-images-1.medium.com/max/1024/0*eD2CGJYG80mYacl3.jpg)

Pantavisor Linux is an embedded framework for building, maintaining, and managing LXC containers. It presents an infinite number of possibilities for running applications at the smart device edge.

In this use case, we’ll describe how to run containerized GUI applications that communicate via a socket to a containerized version of [Wayland Composer](https://wayland.freedesktop.org/).

### Use Case

![](https://cdn-images-1.medium.com/max/1024/0*2eWgKJNhnQBQRwK2.png)

We will run two different applications for this example:

- **qt** : An opensource application written in [QT](https://www.qt.io/). You can see the source code for the application [here](https://github.com/onyazuka/Simple-system-monitor). The built container for it is here: [https://hub.docker.com/r/highercomve/qt-system-monitor](https://hub.docker.com/r/highercomve/qt-system-monitor)
- **flutter-example** : This is another application built with [Flutter](https://flutter.dev/). Flutter is a framework developed by Google to build iOS, Android, and Desktop apps written in [Dart](https://dart.dev/multiplatform-apps). We will use the default [example Flutter app from Flutter](https://flutter.dev/docs/get-started/test-drive?tab=vscode#create-app)

Both **qt** and **flutter-example** are built with Ubuntu containers that run in another Ubuntu container.

You can see the source code for the application containers here:

- **Flutter-example** : [https://gitlab.com/highercomve/flutter-weston-example](https://gitlab.com/highercomve/flutter-weston-example)
- **qt** : [https://gitlab.com/highercomve/qt-simple-system-monitor](https://gitlab.com/highercomve/qt-simple-system-monitor)

For the Wayland protocol and compositor, we selected [weston](https://gitlab.freedesktop.org/wayland/weston). Weston can be described as the reference implementation of a Wayland compositor. It is also a very useful environment in and of itself.

With this, we now have the three base containers that will do the work of running the application and then displaying it on the monitor.

### Before You Begin

You need a Raspberry PI 4, a display, an HDMI cable, and a mouse and keyboard connected to the Raspberry PI. By default, weston does not start without a connected keyboard and mouse.

You can download a Pantavisor image and claim it at [hub.pantacor.com.](https://hub.pantacor.com) If you don’t have an account on [hub.pantacor.com](http://hub.pantacor.com), create one and then claim the device by following this [Getting started guide](https://docs.pantahub.com/get-started/).

### How this works

Because this demo is fairly straightforward, and also to make things simpler, you can clone and deploy my reference device directly to your device with:

```
pvr clone https://pvr.pantahub.com/highercomve/gui_rpi64
cd gui_rpi64
pvr post -m "Add weston, flutter example and qt example" YOUR_DEVICE_CLONE_URL
```

Those commands will push all the parts needed to your device so that you can see everything running. Inside the reference device is the following folder structure:

- bsp
- awconnect
- pv-avahi
- weston
- flutter-example
- qt

With all those containers we are going to build a communication system for the Wayland components that will work in this way:

![](https://cdn-images-1.medium.com/max/1024/0*wazsBxRSrwnZm4pn.png)

You can read more about how Wayland works in their documentation about the architecture. But let’s dig into how this container works from the pantavisor perspective and how every container is built and how it works.

### BSP

The bsp folder contains the Board Support Package. It is also where Pantavisor runs.

### awconnect

This is the main container and platform for the system. It is very similar to the base OS for all running containers. The awconnect container is also the central point in the example app architecture with weston. Weston will use any sockets configured inside the awconnect container. This container will then pass the info down to the kernel, etc.

### Sharing sockets in the awconnect container

To share sockets running in the main container, you must configure the storage parameters inside the awconnect src.json file.

First, mount a permanent volume inside the /var/run/dbus folder of awconnect. This allows you to read and write from any container that wants to send its data to the monitor.

To do that the awconnect src.json should look as follows:

```
{
  "#spec": "service-manifest-src@1",
  "args": {},
  "config": {},
  "docker_digest": "registry.gitlab.com/pantacor/pv-platforms/wifi-connect@sha256:5c889720c6243408049b7a2f9ec75b9f4e376f6cbc28e39e091420a1e19df2aa",
  "docker_name": "registry.gitlab.com/pantacor/pv-platforms/wifi-connect",
  "docker_source": "remote,local",
  "docker_tag": "arm32v5",
  "persistence": {
    "/var/run/dbus": "boot"
  },
  "template": "builtin-lxc-docker"
}
```

### How the Weston container is built

The weston container is built with alpine and also includes all of the packages to make the Wayland Compositor work with weston.

You can see the source of this container [here](https://gitlab.com/pantacor/pv-platforms/alpine-weston).

The Dockerfile generates the container. It will look exactly like any other normal Dockerfile, since there is nothing different that needs to be done to make a container run in Pantavisor.

However, the most important part is not the container itself, but rather the Pantavisor configuration inside the src.json file. It is here that we need to be able to read and write to the socket folder kept inside the awconnect container.

```
{
  "#spec": "service-manifest-src@1",
  "args": {
    "PV_LXC_EXTRA_CONF": "lxc.mount.entry = /volumes/awconnect/docker--var-run-dbus run/dbus none bind,rw,create=dir 0 0\n",
    "PV_RUNLEVEL": "platform"
  },
  "config": {},
  "docker_digest": "sha256:116cc7d42d3f7e513fad55688b618e61dcdae2dd37f8164a86eea80af00c03d9",
  "docker_name": "weston",
  "docker_source": "remote,local",
  "docker_tag": "latest",
  "persistence": {},
  "template": "builtin-lxc-docker"
}
```

All the docker\_\* parts of this file are generated using:

```
pvr app add --from=registry.gitlab.com/pantacor/pv-platforms/alpine-weston:arm64v8 weston
```

### Adding Docker apps to Pantavisor

You can use the pvr app add command to add more Docker applications, and to basically convert any Docker container into a Pantavisor container (just a normal LXC container but with our tooling to make it easy to manage). See: [Adding Apps from Docker](https://docs.pantahub.com/pvr-docker-apps-experience/) for more information.

### Communicating with the awconnect

To enable the weston container to talk to the awconnect system, the following two arguments were added:

**1.- PV\_LXC\_EXTRA\_CONF**

This configuration allows the pvr commands to extend the default LXC generated configuration. It is necessary to add extra LXC configuration in this way because when pvr updates or installs the container it also needs to generate the LXC configuration file.

In here we configure the lXC container to mount the same volume of the /var/run/dbus on awconnect inside a /run/dbus folder with read/write permissions.

The route of the awconnect volume is defined in the run.json file for that container. We will mount it using the LXC configuration parameter lxc.mount.entry

You can read more about the LXC configuration in the [documentation](https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html)

The end result of that configuration will be:

```
lxc.mount.entry = /volumes/awconnect/docker--var-run-dbus run/dbus none bind,rw,create=dir 0 0
```

**2.- PV\_RUNLEVEL**

The PV\_RUNLEVEL argument configures the level of priority used to run the container. By default, all applications run in RUNLEVEL: app and all apps in that run level will wait for the platforms to start.

With this configuration, the container should run correctly and it will act as the wayland composer.

### flutter-example and qt

And lastly, we have the containers that will run the GUI applications. As I mentioned before, they are built with this source code:

- **flutter-example** : [https://gitlab.com/highercomve/flutter-weston-example](https://gitlab.com/highercomve/flutter-weston-example)
- **qt** : [https://gitlab.com/highercomve/qt-simple-system-monitor](https://gitlab.com/highercomve/qt-simple-system-monitor)

And the configuration for both of them will be similar to the weston platform where we are going to modify the args value of the src.json in order to mount the awconnect volume with the sockets and configure both containers to run on RUNLEVEL platform.

### Display the results

After you’ve posted everything to your device and the device consumed the revision, the Raspberry Pi will restart. You will then see the System monitor application written on QT and the Flutter example of a counter clicker running on the Raspberry PI display.

![](https://cdn-images-1.medium.com/max/1024/0*eD2CGJYG80mYacl3.jpg)

Is important to know that you can install to a container any available application from your favorite Linux distribution (example: Ubuntu) with support for wayland. That means you will install more packages than it needs, but it is possible.

I recommend that you look insides of the flutter-example and the QT system monitor containers to see the dependencies needed for the applications to run.

### Final Thoughts

If you have any questions or you want to know more about [Pantavisor](https://www.pantavisor.io) and [hub.pantacor.com](https://hub.pantacor.com) you can reach out to us on [@pantahub](https://twitter.com/pantahub) on Twitter or join our [Pantavisor Slack channel](https://pantavisor.slack.com). We’d be happy to help.