Multiple virtual servers (LXC containers) possible?

Say one wants to run several virtual servers (containers if you will) that will mostly be idle (e.g. VPN / SSH-tunneling, backup-NAS, LAMP-mail+webserver) alongside the “standard” Omnia routing (security)services.

  1. Is it in possible to have multiple LXC containers running or will it be limited to one (in principle LXC would typically support this, but will Omnias default firmware allow for it)?
  2. If yes: Do you guys/girls think the Turris Omnia will be powerfull enough for the aforementioned use-cases*?
  3. Will the GUI have (rudimentary) support for starting / stopping the container(s)?

*Note that - in my case - the services will rarely all be active at the same time (e.g. backups will run only at night, so typically when I am not using my VPN etc.). Also my web-services are private with virtually no traffic :pensive:.

2 Likes

+1
the same scenario question here

The 2GB RAM upgrade was introduced for users that would need more than 1GB for example for running more (not more than one, but more than is possible with 1GB RAM) services or containers.

Thanks for adding to the discussion Paul,

Indeed the 2GB RAM perk opens up more “breathing space” for running more stuff in general (esp. memory-wise). I therefore ordered it alongside the Omnia as well :sunglasses:. But I explicitly do not want the services to run (directly) on top of openWRT. Instead they need to run as if on unrelated, separate, “servers”. My questions are therefore fairly specific (with one added in the mean time):

  1. Is it - in principle - possible to run multiple mutually independent (other than having a shared kernel by LXC definition ofc.) containers in parallel using the default firmware (ofc. some configging may be necessary)?
  2. Is the Omnia powerful enough to run the aforementioned services, what would be the bottlenecks to take into account (RAM is one thing, as is CPU, but what about having to run it from an ext.HD, any other possible snags)?
  3. Will the (G)UI have an interface to (re)start/stop/clone/snapshot the custom containers?
  4. Will it be possible to actually “run” (“chroot”-ish) Debian and will these containers be portable to non-ARM kernels?

I’m asking as the containers are supposed to replace my Raspberrypie-“servers” and I want to practice my (Debian)CLI skills (how can I do that better than on “the open source center of your home:heart_eyes:.

Any (official) answer on this matter (sorry for the sheer amount of questions, but they should be fairly simple and I’m sure others would like to know as well)?

Edit: In the mean time this post about LXC virtualising Debian may be of interest for readers of this thread too (possibly even placing this post in its shadows).

  1. It should be possible, and i have no idea why it should not work :wink:
  2. “It depends”. Anyway, lxc overhead is minimal. You can create vm with such amount of ram and openwrt to have basic understanding of service memory/cpu consumption. Or just wait when board will be arrived )
  3. There is very basis support in LUCI gui, i have no idea about forris, i never using it (okay, i am using it for initial setup only ;))
1 Like

Thanks @samm_git for the knowledgeable reply!

Anyone knows about kernel support? More specifically about portability of LXC containers between kernels; would a container running on the Omnia be (ex)portable to another system, say to an Intel i5 based laptop or something similar (read: non-ARM)?

No, it wont be portable. Only Linux ARM containers will be possible to run.

1 Like

Yah… I figured as much. The price one pays when vitalizing on OS level I guess. But one that I happily pay in order to keep things light weight!

The concept to cut out a lot of overhead that is not (always) needed is really nice. I read that there are some difficulties to tackle when one wants to have containers run unprivileged though?

  • Anyone know how the Omnia deals with this (will it run containers (un)privileged)?

I am so looking forward to virtualize on the Omnia! Like I wrote before; its one of the main reasons for me to choose this open source project to support.

1 Like

@samm_git (or anyone else really):

What would be a good way to export/import (say the Omnia dies on me and I would want to run the containers elsewhere after it)?

I would like to have them portable or even distributable (in a “docker” kind of fashion)!

Or is that simply not do-able using LXC?

A container’s file system is accessible to the host so you can back it up just as any other.

Why don’t you start playing with lxc right now? If you have access to a Linux-based system you can start using it right now and gain lots of experience until the Turris arrives.

That is very good advice! I indeed have played a little and have several tests running: 1 host (+1 container) at work and 2 hosts (each having 2 containers) at home.

But I have never mixed and matched architectures (they are all non-ARM kernels, whereas the Omnia is ARM based) and I was was told that they can’t be migrated cross-architecture:

Normally I would simply TAR the guest file-system, but seeing I need portability cross-architecture… I am a bit unsure how to deal with it.

Take a Raspberry Pi 2 or something like that. It is ARMv7 and is portable to other ARMv7 devices like the CPU in Turris Omnia.

On the other hand is moving a container between different hosts the same on any architecture. If you move a container from PC A to PC B it works the same way as moving from one Turris Omnia to another one.

Side note: the Raspberry Pi (A,B,A+,B+,Zero,Compute Module) models based on the BCM2835 will not run containers built for ARMv7 or newer but the ARMv7 or newer models (2,3) will run the old containers. It is a bit like running a 32bit container on a 64bit PC.

1 Like

Salvation at last! So as long as I stay within ARM and buy the same or newer generation for a new host, I can migrate to it? Nice! I was about to buy a Rpi3 as a multimedia streamer anyway; so that may double as my LXC backup host environment!

  • I will have to look whether Raspbian (my preferred Rpi distro) has LXC support / packages for it though.

(The older one - based on Debian7 - did not, but the newer Debian8 based version may).

P.S. Not that I expect the Omnia to fail soon though, I’m simply always exploring options to prevent being locked-in or end up at a dead end (support wise).

Thanks for all your answers / suggestions guys! This way people can prepare and be ready once the Omnia gets shipped!

So everyone will be ready but not me. :sob:

[quote=“adminX, post:14, topic:443”]
So everyone will be ready but not me. :sob:
[/quote]How is that? Why wouldn’t you be?

The plan is to run ArchLinuxARM and use the dsa driver for the switch chip. This will end in patching the kernel. Checking drivers without hardware is kinda useless. And after getting this up freeswitch is on the list. It seems to have some problems with timers so this may need additional work. I do not want to fallback to some cpu-time-burning failsafe timer. This did not even touch any of the more fancy things like adding GPS including PPS, a RFM12 and other hardware on the extension connector.

aaaaaaw… :cry:

I know it is probably futile; but why not go with Debian?

To be fair; I only get half of the stuff you wrote so you may already have stated why (or you simply prefer Arch for other reasons)?

I didn’t like debian for its configuration files. It was too different compared to my Red Hat. This was some years ago. So my first ARM device got ArchLinuxARM and all other followed. Other point was debian’s mostly antique software versions at that time.

nods For me it is the exact other way around. I was first confronted with Debian. I like its pure “FOSS” philosophy, and stability; hence I accept the “antique” application versions (on the other hand Debian-testing is, in most cases, still more stable than bleeding edge distro’s). But indeed each user/use-case its own Linux; that’s the beauty of Linux!

But we (me mostly) are drifting off-topic.

  • You guys reckon the Omnia will be stable / fast enough to run a LAMP+mail-server?

Will it run fast enough from an external USB3 HD, or do I really need to run the containers it from an internal mSATA SSD?

[quote=“woosting, post:4, topic:443”]will these containers be portable to non-ARM kernels?[/quote] It’s not the problem of the kernel, containers are just tied to an instruction set as there is no virtual machine. if you want this kind of portability i suggest using kvm, however i doubt that turris openwrt supports this.