Help with LXC on virt-manager

Got a few VMs working great on my Fedora 25 server. My problem is I want to start learning containers. I am using virt-manager and setup an LXC container I believe. Have searched over last few days and cant find a good tutorial on LXC using virt-manager.
When I connect to container1 on LXC through VNC form virt-manager i basically have a command prompt with sh-4.3#.
A few questions:
How do I build a container form virt-manager from template?
Is there a way to have virt manager show me all the lxc templates or do I download each one I want and store in directory for Virt-manager to allow me to pick from?
Anything other useful info you have would be great. I feel dumb asking but I guess I am lost as where I am at right now. I have probably passed over a good tutorial through my digging because it wasn't a tutorial using strictly virt-manager and my knowledge is not good enough for realizing what the tutorial is doing through command line.

1 Like

Ok so not sure how I missed this:
http://fabian-affolter.ch/blog/lxc-with-virt-manager/
But I know I have setup a container the same way but now I am wondering what to do with this container I have?
I thought the selling point of containers was the templates?
Can I setup a user on the container or do I just run everything as root?
Do I treat it like a VM and install whatever I want on it?

1 Like

That entirely depends on if it's an OS container or an Application container.

OS containers would use the templates. Application containers usually only contain the binaries needed to do the one thing you made the container for. i.e. you can put your web browser in a container so that if something happens, it's effectively in a sandbox.

Now, that's the idea, but I have yet to understand how that is supposed to work. Part of the problem is that whenever I try to research Application Containers, Docker comes up. The reason that happens is that Docker uses LXC as it's backend for application containers, but having never used Docker, I don't know what is relevant only to Docker and what is useful for all LXC Application container usage.

I've actually read that tutorial you linked, but I'm in the same boat you are. I figure those are for Application containers though, so they wouldn't use the templates.

I started watching this video some time ago, but haven't been bothered enough to finish it yet:

I'd like to learn how to use LXC with virt-manager effectively as well, but it seems like there's not a lot of information for learning how to do that.

One reason I think it's an application container in that guide is because it specifies a binary to load in the container. i.e. the /bin/sh. You could do your web browser or whatever else, I think.

This still doesn't help because then how would you do OS containers? I'm not sure honestly.

1 Like

Yea I had done some research after i posted the last reply and read on the difference between application and OS container. I will not have any use for application container yet but maybe in foreseeable future if things start clicking and I start writing more code and needing more services.
So I guess for now I will work with OS containers and see what I can come up with and hopefully report back here. My understanding is I can run a different OS but it will use my host kernel. I assume this will be better performance than a VM. Anyways thanks for your reply and I will keep working at it and report back.

That is not true anymore. Since 0.9 they use libcontainer. Source

And it is not necessarily the reason why all your searches for "container + something" return docker. They (the company behind docker) are just much better at marketing. At some point a huge load of people learned the concept of containers when they learned about docker. So docker = container.

1 Like

This is correct. Here some benchmarks against kvm (LXD is a daemon that uses LXC and brings many nice features you want in a data center or cloud, e.g. API access or image index).

About your virt-manager troubles:

I recommend you start using lxc on the command line it is very easy. You basic commands are

lxc-create -n NAME -t TEMPLATE
lxc-start -n NAME
lxc-stop -n STOP
lxc-attach -n NAME # gives you a shell in your container
lxc-ls -f # f for fancy
lxc-freeze -n NAME # if you need to suspend your container

And so one. Just take a look at man lxc*. There are many man pages about commands and config files.

There are two types of contexts for containers: privileged containers and unprivileged containers. Those run by the system (root) are by default privileged. When something escapes your privileged container they are root.

virt-manager by default connects to the system session of LXC (i think). That means privileged containers are running under root.

When using the wizard in virt-manager (1.4.0 on my system) it asks you for the location of the os container. It appears to me that it does not support the creation of lxc containers.

But luckily for you LXC containers are by default only directories (iif configured also btrfs subvolumes, zfs volumes, LVM or overlayfs). But you might need to change the permissions. virt-manager uses libvirt, so it might try to access the container with with that user.

I recommend you take a look at the great blog series by a LXC dev:

LXC 1.0 blog series

If you are interested about LXD on fedora click this way

2 Likes

Will check all this info out tomorrow. Appreciate it.

2 Likes

So I was thinking last night about the application container and watching that video at the top where he has a Ubuntu system with Chrome and Steam in a Container working. I now have the idea to have a base Antegros system install with Gnome and Chromium. Say I want to setup and mess with Git I will setup a container and setup Git in the container and if i just bomb the setup maybe be able to destroy container and start over again without having all these files and packages installed to my base OS. This is something I have thought of for a while without the knowledge of how to efficiently do it. I feel in my learning on Linux that I will install and try something and mess up the setup or run into an error or just not like the program and after a few months of this makes me feel like my system is cluttered with unnecessary junk and not everything gets removed when uninstalling package. This is something I am going to work with and see if it works like it is running in my head.
Any feedback of pros and cons on this approach? Git may not be the best thing for what I am trying to say but anyways let me know your thoughts on this approach.

1 Like

That's exactly what I want to do as well, and I believe that's one of the many positives of application containers.

My issue with Arch (and thereby, Arch based distros) has always been that since I manually install everything, I probably mess up a lot and leave things behind but don't realize it and feel the same way you do. That my OS has stuff I'd rather it not, but I'm not capable enough to know how to easily deal with said issues.

Application containers solve that. They also add a level of security that's pretty strong.

What I don't understand (I haven't finished that video though) is how, if an application container still uses my host's file system, how is it secure? And if the files are installed to said filesystem, how does it know what to remove that should be in the container vs what isn't?

I guess the basic answer for that is "designate a location for the container only like a btrfs subvolume or whatever", but then don't I have to duplicate my file system in that location and give the application what it needs to access anyway?

I don't really get how the layer of abstraction works. I should really finish that video though.

My ideal is to be able to install and switch on/off a web server, database, and script engine on my server. i.e. Apache, with MariaDB, and PHP, or nginx, with MariaDB, and Python, or wtv. Just for learning purposes. Where it's all self-contained and if something escapes the container, it's just a useless container user.

I think that's how that'd work though. Unprivileged containers that are created and ran with some user who only has the permissions to do that and literally nothing else.

Yea finish watching the video and they show separate containers running a single service and then you can interconnect those containers. I am staring at my terminal now about to start messing with it but got TeamPGP stream from last night going and keep getting distracted.

1 Like

Git is a very good method to version files you use within the container. Just make sure to save your important git repositories before destroying containers.

If you want simple versioning of containers you can use snapshots. But this feature needs some "advanced" storage or takes a lot of space (if you only use "dir" as data backend).

A very good solutions are backups. I recommend borg which is very efficient and easy to use. I use it to backup containers in production and it is very fast and saves a huge amount of space. (I have snapshots with btrfs anyway, but those are not backups.)

[quote="Vitalius, post:9, topic:114235"]
What I don't understand (I haven't finished that video though) is how, if an application container still uses my host's file system, how is it secure? And if the files are installed to said filesystem, how does it know what to remove that should be in the container vs what isn't?[/qoute]

Think of a separate mount. The container does not see your whole file system because it has its own imaginary file system that only has a subset of files of your host system. (Usually only the rootfs of the container).

The real answer is Linux namespaces and it does a lot more than only file system stuff.

Every time a process in that container ('s control group) wants to access a file your host OS looks if that control group can access that resource.

I guess the basic answer for that is "designate a location for the container only like a btrfs subvolume"

No. If you use the backend "dir" (default) it uses the same file system. But the access from the container is restricted (isolated) so it only sees what is in /var/lib/lxc/CONTAINER/rootfs and everything you mounted manually (which i assume you did not). OS containers have a full file tree there. Application containers only have "data" there and everything else comes from your hosts OS file tree.

but then don't I have to duplicate my file system in that location and give the application what it needs to access anyway?

Only virtually.

My ideal is to be able to install and switch on/off a web server, database, and script engine on my server. i.e. Apache, with MariaDB, and PHP, or nginx, with MariaDB, and Python, or wtv. Just for learning purposes. Where it's all self-contained and if something escapes the container, it's just a useless container user.

Not 100% sure but you might want to look into systemd-nspawn.

Always name the source. :stuck_out_tongue:

Which video were you watching?

1 Like

It's in this thread. LXC in the wild. It's up there. That's what we were discussing at the moment.

2 Likes

I'm getting it more now. That makes more sense.

Just as an update I got all my vms moved over to ubuntu 16.04 lxc containers on my fedora 25 rig. Thanks for all the help guys.

1 Like

Are you using virt-manager or did you drop it completely?

Dropped it completely