[lxc-users] Converting from libvirt lxc

[Peter Steele]

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 
> <mailto: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
>>     <mailto: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?

>
> Short version: if you use 
> http://copr.fedoraproject.org/coprs/thm/lxc1.1/ , you need to do some 
> things first:
> - edit /etc/sysconfig/lxc, USE_LXC_BRIDGE="true"
> - systemctl enable lxc-net
> - systemctl enable lxc
> - systemctl start lxc-net
> - brctl show
> - ip ad li lxcbr0
> If you HAVE lxcbr0 with the default ip 10.0.3.1 (you can change this 
> later), you're all set. If not, doublecheck your setup.
> If you're asking "where's the docs that mention this", as the package 
> manager :)
>
> 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.

There *are* other issues (our software isn't running properly), but I 
think the major container issues have been resolved. 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.

> # lxc-start -n c7;lxc-console -n c7 -t 0
>
> The benefit of using this approach instead of "lxc-start -F" is that 
> you can detach the console session later using "ctrl-a q". Note that 
> you can NOT login on this console yet, as by default the root password 
> is not set. From another shell session, you need to do
>
> # lxc-attach -n c7 -- passwd
>
> Then you can login from the console session. You'll then see on the 
> container (I tested this just now on up-to-date centos7)
>
> [root at c7 ~]# ls /dev
> console  core  fd  full  hugepages  initctl  log  lxc  mqueue  null 
>  ptmx  pts  random  shm  stderr  stdin  stdout  tty  tty1  tty2  tty3 
>  tty4  urandom  zero
>
> Apparently this works even without lxfs.
>
> 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.

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