I would like to run an OpenVPN client inside of an LXC container in order to isolate several applications which must only use a certain OpenVPN connection. I understand that this is probably possible to do using careful routing, but I want to guarantee that these applications (which use several protocols and multiple TCP/UDP ports) absolutely cannot use the default route. My issue is that the provided 32-bit Arch kernel does not provide a few necessary kernel options:

[root@blah blah]# lxc-checkconfig
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: required
User namespace: missing
Network namespace: missing
Multiple /dev/pts instances: missing

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: missing
Macvlan: missing
Vlan: enabled
File capabilities: enabled

I would switch to pv-grub, but the stock 32-bit Arch kernel does not support xen, and the 32-bit Arch kernel with xen support in the AUR is extremely out of date.
I could compile my own kernel and keep it up to date, but this would be an annoyance. Is there any chance we could get these options compiled into the next provided 32-bit Arch kernel? CONFIG_PID_NS and CONFIG_NET_NS would probably be sufficient for OpenVPN, but I'm not totally sure.

Alternatively, if anyone knows of a better way to guarantee that certain processes will only use an OpenVPN connection, and that other processes will not have this OpenVPN connection available to them, I would certainly be interested.

I would also very much like to have these options enabled in the Linode-provided kernels.

While it would be an annoyance, I'd suggest rolling your own kernel. We try to keep our kernels as slim as possible while still providing functionality that a large number of users can benefit from. Anything outside of those features would require running the distribution-supplied kernel, or compiling your own.

It also appears that the x86_64 Arch Linux kernel may have DomU support built in, as mentioned in the comments for the AUR:

- https://aur.archlinux.org/packages/linux-xen/

-Tim

_________________
'If debugging is the process of removing bugs, then programming must be the process of putting them in.' //Edsger Dijkstra
'Nothing is withheld from us which we have conceived to do.' | 'Do things that have never been done.' //Russell Kirsch

LXC is based on some fairly standard features found in recent kernels (>= 2.6.29), called cgroups and namespaces, which are combined to form a sort of super-chroot() called a "container". The kernel versions that Linode runs (3.8 and 3.10) are almost always built with full container support, and an increasing amount of software (especially server software) assumes working containers. The current Linode configuration causes issues when attempting to run modern daemon management software such as Systemd and Docker, which use containers heavily.

There are a significant number of ad-hoc tutorials on the web for how to get a working container-enabled kernel on Linode, usually involving some customized distribution kernel plus pv-grub magic. It would be much easier for users if this commonly used kernel feature were enabled by default in Linode's kernels.

The following kernel options are required for a fully functioning container setup (from http://lxc.sourceforge.net/man/lxc.html). Even if some of them can't be added to the Linode default kernels (e.g. due to being experimental), it's still useful to have as many of these as possible:

* General setup
  * Control Group support
    -> Namespace cgroup subsystem
    -> Freezer cgroup subsystem
    -> Cpuset support
    -> Simple CPU accounting cgroup subsystem
    -> Resource counters
      -> Memory resource controllers for Control Groups
  * Group CPU scheduler
    -> Basis for grouping tasks (Control Groups)
  * Namespaces support
    -> UTS namespace
    -> IPC namespace
    -> User namespace
    -> Pid namespace
    -> Network namespace
* Device Drivers
  * Character devices
    -> Support multiple instances of devpts
  * Network device support
    -> MAC-VLAN support (can be a module)
    -> Virtual ethernet pair device (can be a module)
* Networking
  * Networking options
    -> 802.1d Ethernet Bridging (can be a module)
* Security options
  -> File POSIX Capabilities

Just a note, the Ubuntu 12.04 stock kernel fully supports lxc and xen, also the lxc package is very good with useful cli utilities. I know it's not arch but if you don't mind switching distro it works great on both 32 and 64 bit. I have a 32 bit instance running LXC on Linode and 64 bit instances on dedicated servers.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

How many people are using CONFIG_ATA_OVER_ETH ? Can we swap that out for the LXC stuff?

-- Kevin