LXC

In a follow on post to my previous GUI From an LXC Container on the Host entry, here are some notes on linking sound in an LXC container to the host's sound system.

The primary reason for this was to get around Interactive Broker's broken sound requirements for really old libav libraries. Which is back to the version x53 libraries from the Debian Jessie / Ubuntu Precise 12.04 days. Long story short, I don't have this working yet. The basic issue I have is that, when running TWS in an LXC container, all the configuration menu options but one work. When I click on the 'Sound Manager' menu item, TWS locks up, and I don't see any log messages anywhere as to why this might happen. So there is something special in an LXC container environment which is locking up sound in TWS.

But I did get sound from FireFox / Youtube to work.

This on a Debian Bullseye system.

The basic solution is, in the LXC container configuration file, to mount the Pulse Audio socket from the user's account of the host into the container and set an environment for the user in the container. In this case, the user has UID of 1000:

lxc.mount.entry = /run/user/1000/pulse/native tmp/pulse/native none rw,bind,create=file 0 0
lxc.environment = PULSE_SERVER=unix:/tmp/pulse/native

For completeness, these can be added (helps with ALSA):

lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir
lxc.cgroup.devices.allow = c 116:* rwm

That is about all to make it all work. Some or all of the following package installs in the container might help:

sudo apt install \
  pulseaudio \
  pulseaudio-utils \
  pavucontrol \
  gstreamer1.0-libav gstreamer1.0-plugins-bad gstreamer1.0-pulseaudio \
  mpg123

For some machines with LXC containers, they have been running for a number of years. I want to take the easy way out and move the containers from one physical machine to another. At another time, I will rebuild the containers.

Since I am running BTRFS subvolumes for each container, I could be using BTRFS snapshot/send/receive commands to migrate/copy/replicate subvolumes. But before attempting that, I wanted to give the 'copy' a try. To do this properly, at the source, use the following -- with numeric-owner being a required paramenter -- command to collect the files:

tar --numeric-owner -czvf mycontainer.tar.gz /var/lib/lxc/my_container

At the destination, expand that file out:

tar --numeric-owner -xzvf mycontainer.tar.gz -C /var/lib/lxc/

The lxc users mailing list and Stack OverFlow were helpful.

Other stuff to do:

• Read up on CGroups in the Linux Programmer's Manual

In migrating from a very old version of LXC to a much newer version of LXC, I was getting errors. I needed to run a some debug to get a handle on errors:

lxc-start -n container -F --logpriority=DEBUG --logfile log

I had errors along the lines of:

Activating lvm and md swap...done.
Checking file systems...Segmentation fault (core dumped)
failed (code 139).

ServerFault had the solution: put "vsyscall=emulate" into /etc/default/grub, run 'update-grub' and reboot. Looks like I need to modernize my containers so I can eliminate this workaround, which may have some security considerations. There is a Debian Bug for this.

einstein home has a blog with some kernel references to the issue, in effect saying: "vsyscall is now disabled on latest linux distros". A lengthier LWN article at On vsyscalls and the vDSO. This works with kernel 4.14, my current version, but I see somewhere else that the workaround is entirely removed in kernel 4.15, at least in the Arch world. At bug 847154: "This breaks (e)glibc 2.13 and earlier".

• Configuring network namespaces in Linux
• manage kvm virtual machines

Policy Based Routing: using named routing table in Linux, a basic outline:

With Quagga, no. But you can implement it in the Linux shell. Examples
from Ubuntu:

1. First create a named routing table in /etc/iproute2/rt_tables
200 MY-TABLE

2. Then create routes in that table:
ip route add default via 172.16.0.1 table MY-TABLE

3. Finally, create the policy:
ip rule add from 10.0.0.0/29 table MY-TABLE

See all the "ip rule" commands for full details. I do a lot of this. 

I'm in the process of figuring out Docker, and how to make it run on Debian. These are just 'notes to self' to look at for another time. I am reverting to lxc (linux containers) for the time being.

• Debian package for Docker is still several versions behind (with the current appearing to be v1.50 from 2015/02/03, see Docker release notes). It is better to download the binary from Docker.
• Some notes using Docker in a multi-host environment: Multi-host Docker and OpenvSwitch
• Some web sites suggest 'apt-get install docker.io' on Debian Jessie to install Docker. Even the Docker site says this: Docker on Debian Jessie. But that command does not work as of this writing.
• Debian doesn't seem to have an official base image, just a semi-official base image, but really not really, based upon some reading which says that some kluges went into building the base image.
• Some other pointers for a Debian Jessie base image stuff: debian docker base image, Installing Docker on Debian Jessie (from 2013), Installing Docker in Debian (testing/Jessie) (also 2013) , CloudCreateDockerImage

But then, all this might be irrelevant. There is something called CoreOS, which is a ground up solution for running containers.

On my Debian 7 Wheezy systems running LXC, I have recently seen libvirt_lxc go up to 100% cpu utilization on a continuous basis. The brute force fix was to restart the guest. But that isn't a good idea.

There is a suggestion at [Bug 1005570] libvirt_lxc consumes 100% cpu - msg#00023 that:

When this 100% cpu problem occurs, can anyone tell me if they still see a process running as a child of the 'libvirt_lxc' process ? Whether a zombie or normal process.

Looking at the code, the only way I can see us getting into this problem, is if the guest closed its console (STDIO) streams, but did not exit. We should always get SIG_CHILD if the process exited, so I'm thinking perhaps the container's init process closed stdin/out/err, but kept running

When I logged in via the lxc console as root, the high cpu utilization went a way.

As a side note, to login as root via the lxc console, I had to add 'pts/0' to /etc/securetty. I also only have one tty listed in /etc/inittab:

# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin
1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

Let me see if these settings actually help prevent further recurrence of the high cpu usage in libvirt_lxc.

Now that the networking side of things are complete with Quagga and OpenVSwitch, I can start working further up the technology layers. The next step is to work on virtualization technologies and their management. The focus of this article is to get Linux Containers (LXC) working within a Debian Wheezy 7.1 environment. Continue reading "Linux Containers (LXC) on Debian Wheezy 7.1..." »

As part of the virtualization solutions I'm working on, I wanted something a little lighter weight than a full Qemu/KVM solution, which has a higer overhead than a kernel oriented container mechanism. There are many services that can be run with a common operating system. Containers provides the ability for solid segregation of services at the price of very low overhead.

For a container style of virtualization, I had been looking at OpenVZ (which is used by Parallel's Virtuozzo, I believe), Linux-VServer, and VirtualBox. However, on Debian's Upgrade Path to Wheezy, I see that Debian is deprecating OpenVZ and Linux-VServer.

Independently of this, I had earlier come across lxc Linux Containers. As such, it looks like LXC is the path forward for light weight, container-based virtualization.