Lxc Without Chroot

LXC without chroot

LXC isn't a monolithic system. It's a collection of kernel features that can be used to isolate processes in various different ways, and a userspace tool to use all of these features together to create full-fledged containers. But the individual features are still usable on their own, without LXC. Furthermore, LXC does not require a chroot, and even when you give it a chroot, you can bind-mount directories from the host system into the container, sharing those particular directory trees between the host and the container.

For instance, cgroups are used by LXC to set resource limits on containers. But they can be used to set resource limits on groups of processes without using the LXC tools at all. You can manipulate /sys/fd/cgroup/memory or /sys/fs/cgroup/cpuacct directly, to put process into cgroups that limit the amount of memory or CPU they are allowed to use. Or if you're on a system using systemd, you can control the memory limits for a group of processes using MemoryLimit=200M or the like in the .service file for a given service.

If you want to use LXC to do lightweight resource management, you can do that with or without a chroot. When starting an LXC container, you can choose which resources you want to isolate; so you could create a container with only a virtualized network, and nothing else; or a container with only memory limits, but sharing everything else with the host. The only things that will be isolated are those specified in the configuration file for your container. For example, lxc ships with several example container definitions that only isolate the network; they share a root partition and almost everything else with the host. Here's how to run a container identical to the host system except it has no network interface:

 sudo lxc-execute -n foo -f /usr/share/doc/lxc/examples/lxc-no-netns.conf /bin/bash

If you want some files to be shared with the host, but not others, you have two choices; you could use a shared root directory, and mount over the files that you want to be different in the container; or you could use a chroot, but mount the files that you do want to share in the container.

For example, here's the configuration for a container that shares everything with the host except for /home; it instead bind-mounts /home/me/fake-home over /home within the container:

lxc.mount.entry = /home/me/fake-home /home none rw,bind 0 0

Or if you want to have a completely different root, but still share some directories like /usr, you can bind mount a few directories into a directory, and use that as the root of the filesystem.

So you have lots of options, and can choose to isolate just one component, more than one, or as many as LXC supports, depending on your needs.

No lxc-clone found on system

lxc-clone has been deprecated, and replaced by lxc-copy.

Run a program inside an LXC container that is stored on the host

You can make you program to setns(2) (to some, but not all namespaces), chroot and then drop capabilities.

You can also attain something similar with dived (not actually chrooted, but having access to the container's chroot).

You can run [staticly linked] dived inside a container (with the appropriate options, for example, --client-chroot --root-to-current), listening UNIX socket on some filesystem part that is visible both in the containter and on the host; and run dive to ask that dived to start your non-statically-linked program in container's namespace. The root filesystem will stay the same as your host (so your program can find libraries), and the containter's root filesystem will be set as current directory.

segfault appears in linux container start, but fine with chroot?

lxc-start works fine for me, pivot_root is not the problem.

1) just 'lxc-start -n mycontainer' is not good coz it will try to start the init

how about lxc-start -n mycontainer /bin/sh ?

LXC - Linux Containers - Add new network interface without restarting

It would very much depend on the configuration of the interface you're trying to add to the container.

If you have an existing interface on your host which you want to be visible inside the container:

# on the host:
pid=$(lxc-info -pHn foobar)
ip link set dev eth3 netns $pid name eth1

This will cause your host's eth3 interface to be moved to the container foobar, renamed to eth1. This is roughly equal to this configuration:

lxc.network.type=phys
lxc.network.link=eth3
lxc.network.name=eth1

Another useful scenario would be to create a new interface inside the container, bridged to an existing bridge on the host:

# on the host:
pid=$(lxc-info -pHn foobar)
ip link add name veth0 type veth peer name veth0_container
brctl addif br0 veth0
ip link set dev veth0_container netns $pid name veth0

This will create a pair of connected virtual-ethernet interfaces (veth0 and veth0_container), add one of them to the br0 bridge, and move the other into the container foobar. This is roughly equivalent to this configuration:

lxc.network.type=veth
lxc.network.link=br0
lxc.network.name=veth0

LXC using separate HDD/VOLUME

You can create storage pools for each of your disks. Then, when you create a LXD container, you can specify on which storage pool to be created in.

The commands to create the storage pools are:

lxc storage create pool1 zfs source=/dev/sdb
lxc storage create pool2 zfs source=/dev/sdc
lxc storage create pool3 zfs source=/dev/sdd

The commands to launch containers on specific storage pools are:

lxc launch ubuntu:20.04 container1 --storage pool1
lxc launch ubuntu:20.04 container2 --storage pool2
lxc launch ubuntu:20.04 container3 --storage pool3

Do note that such a setup may not be very optimal. See whether you can use either ZFS, LVM, or btrfs. With any of them, you can specify to use all those disks together in some form of RAID. More at https://linuxcontainers.org/lxd/docs/master/storage

Lxc Without Chroot