[lxc-users] Converting from libvirt lxc

[Fajar A. Nugraha]

On Thu, Dec 3, 2015 at 9:27 PM, Peter Steele <pwsteele at gmail.com> wrote:

> On 12/02/2015 08:47 PM, Fajar A. Nugraha wrote:
>
> On Thu, Dec 3, 2015 at 1:14 AM, Peter Steele <pwsteele at gmail.com> wrote:
>
>>
>> On 12/02/2015 07:23 AM, Fajar A. Nugraha wrote:
>>
>> On Wed, Dec 2, 2015 at 9:49 PM, Peter Steele <pwsteele at gmail.com> wrote:
>>
>>> On 12/01/2015 08:25 PM, Fajar A. Nugraha wrote:
>>>
>>> Is there a reason why you can't install a centos7 container using the
>>> download template? It would've been MUCH easier, and some of the things you
>>> asked wouldn't even be an issue.
>>>
>>>
>>>
> lxc-create -t centos -n test1
>>
>> to create a container using the centos default settings. The resulting
>> config file doesn't look a whole lot different than my manually crafted
>> version.
>>
>
>
> You DID notice that repeatedly say "DOWNLOAD template"? as in someting like
>
> # lxc-create -t download -n c7 -- -d centos -r 7 -a amd64
>
> The template was downloaded automatically when I ran the lxc-create
> command the first time. Is there a difference in how the download is done
> using the command you've listed above?
>
>

centos template -> download lost of packages (i.e. RPM) one by one using
yum, and then install it

download template -> download one big tar.xz file (plus several small
config files), and then extract it. MUCH faster, and works for unpriv
containers as well (not sure what the current state of unpriv containers on
centos though)

However I was actually more concerned about the fact that the templates are
maintained separately, so there could be some difference in the resulting
container/config. The download template works (I've tested it), while
(based on your previous output) the centos template doesn't provide the
desired /dev entries.


> The alternative is to configure your own bridge and configure your
> containers to use that. After you get the bridge working, you can start and
> monitor its boot progress with something like this:
>
> That's exactly what I did. I realized this later that the default centos
> container assumes you have a lxcbr0 defined (I had hit this issue before).
> My servers use br0 so I just changed my test container's config and it came
> up fine. Most importantly, the udev service was not running. So I tweaked
> the lxc config I had in my custom install process to more closely match
> what was used in my standalone test and my containers are now coming up
> fine, or at least udev is no longer running. The /dev directory still has
> more entries than my libvirt containers (for example, /dev/snd is still
> present), but at least there are no udev errors in /var/log/messages.
>
>

Which is why I suggested the download template.

I also tested using the resulting config with rootfs replaced by a "native"
centos7 install (to be exact, a disk clone of minimal centos7 install on
virtualbox), still result in the desired /dev entries (i.e. minimal /dev
entries, no /dev/snd).




> There *are* other issues (our software isn't running properly), but I
> think the major container issues have been resolved.
>


Which is?




> I changed a few things, including the version of LXC that I'm using, so
> it's hard to say what the culprit was with regards to this udev issue.
>
>

IIRC systemd containers are only supported on lxc-1.1.x, so upgrading lxc
probably has a big part in that.


>
> If you DO manage to get lxcfs installed and working later (disclaimer:
> I've only use it on ubuntu and debian), you'll be able to get some
> additional benefits like the container only seeing its allocated resources
> (set using "lxc.cgroup" settings on lxc config file). For example, if
> "lxc.cgroup.cpuset.cpus = 0", then the container will only use cpu0, and
> "htop" or "cat /proc/cpuinfo" will only show 1 cpu even when your host has
> multiple cpus.
>
> That would definitely be nice. Libvirt does a reasonably good job in this
> area but it is far from complete, with /proc/cpuinfo being one of the weak
> points. I'll definitely have to check out lxcfs.
>
>

It should be easier now since latest lxcfs shouldn't need cgmanager anymore.

And the usual generic suggestion, if you encounter kernel or
namespace-related problems, testing latest kernel from kernel-ml (
http://elrepo.org/tiki/kernel-ml) might help.

-- 
Fajar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20151203/a4446a3e/attachment-0001.html>