Below you will find pages that utilize the taxonomy term “Lxc”
LXC Project Part 3: Starting and logging into my first container
Continuing my LXC project, let’s list the installed containers:
lxc-ls
That just shows the name of the container - lemmy. For completion’s sake, I’m going to start it as a daemon in the background rather than being sent straight into the console:
lxc-start -n lemmy -d
As per usual Linux SOP, it produced no output. Now to jump in:
lxc-console -n lemmy
That told me I was connected to tty1, but did not present a login. Quitting out via Ctrl-a q let me go back to the VM’s tty, but trying again did not get me login. There’s some weird issue that doesn’t allow it to work, however, this did:
LXC Project Part 2: Setting up LXC
I’m continuing on from yesterday’s post to get the VM ready to host LXC. I’m starting with Centos 7 so the first thing I had to do was enable the epel repos:
yum install epel-release
Then, according to the guide I was following, I had to also install these package:
yum install debootstrap perl libvirt
That installed a bunch of stuff. I also get that they’re trying to break out what they’re doing, but they probably could have installed both that and the LXC stuff below in one blow:
LXC Project Part 1: Bridging the Connection
As I mentioned before, I’m looking at Linux Containers (LXC) to have a higher density virtualization. To get ready for that, I had to create a network bridge to allow the containers to be accessible on the network.
First I installed bridge-utils:
yum install bridge-utils -y
After that, I had to create the network script:
vi /etc/sysconfig/network-scripts/ifcfg-virbr0
In there I placed:
DEVICE="virbr0"
BOOTPROTO="static"
IPADDR="192.168.1.35" #IP address of the VM
NETMASK="255.255.255.0"
GATEWAY="192.168.1.1"
DNS1="192.168.1.7"
ONBOOT="yes"
TYPE="Bridge"
Then, since my ethernet on this machine is eth0
How did I not know about LXC Containers?
Back when I first was working on replacing my Pogoplug (the original BabyLuigi), I was looking at potentially using it to learn about Docker in addition to creating virtual machines that were actually useful instead of just playing around with VMs for looking at Linux distros. The benefit of Docker was to have the isolation of VMs without the overhead of VMs. Also, since it was trending pretty hard, I figured it’d be good for my career to have some experience with it. So I spent a few weeks researching Docker and playing around with some of the online demos. I read lots about how it was used and how to avoid the usual pitfalls. But in the end I went with a VM that did a bit more than I wanted; I’d wanted to separate services so that updating one thing wouldn’t cause me to lose everything. However, the more I looked into it, the more it looked like unnecessary headache without enough of a benefit. Dockers were SO isolated that if you wanted to run a LAMP stack you had to run at least 3 Docker containers and find a way to string them together and have a separate pool of storage they could all access.