[lxc-users] Fedory 20 LXC fails to start on Ubuntu 14.04 host?

Sun May 25 02:08:02 UTC 2014

On Sat, 2014-05-24 at 21:49 -0400, Robert Pendell wrote:
> On Sat, May 24, 2014 at 9:29 PM, Michael H. Warfield wrote:
> > On Sat, 2014-05-24 at 22:00 +0200, Timotheus Pokorra wrote:
> >> Hello Mike,
> >
> >> > 1) Are you running this container unprivileged?
> >> I checked what it means to run a container unprivileged. I think I run
> >> it privileged, I am logged in as root on the host machine, and I am
> >> just trying to start with lxc-start -n myFedora.
> >
> >> > 2) Have you tried creating the container using the -t fedora template?
> >> I tried lxc-create -t fedora -n myFedoraTest
> >> Unfortunately, the result is the same.
> >
> >> >> Anyone any ideas?
> >> >
> >> > The error the OP was showing was a SEGV (11) in systemd.  He did not
> >> > specify how he created the container, or how he was running it (priv /
> >> > non-priv).  A SEGV in systemd would be pretty serious.  It would seem to
> >> > be an executable conflict at a pretty deep layer.  I guess it would also
> >> > be good to know what the host kernel version is as well.
> >> I indeed get the exact same output as the OP.
> >
> >> On the host:
> >> uname -a
> >> Linux j80074.servers.jiffybox.net 3.2.0-60-virtual #91-Ubuntu SMP Wed
> >> Feb 19 04:13:28 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> >
> >> The LXC host (Ubuntu) is a virtual machine running in a XEN environment.
> >> I would understand if that is not possible, but it is possible since
> >> Debian 7 and CentOS 6 containers run fine on this host.
> >
> > XEN???
> >
> > Oh crap...  It's information like this that is critical to understand
> > what's going on.
> >
> > You're in an environment with a Fedora 20 container running on an Ubuntu
> > virtualized host in a Xen guest running under a Xen paravirtualization
> > hypervisor.  Without knowing this, it would be impossible to even guess
> > where the problem may lay (even with this information, it may be
> > impossible).  I haven't even begun to attempt to reproduce it but the
> > number of independent variables just shot through the roof.
> >
> > First order of troubleshooting.  Eliminate independent variables...
> >
> > Have you attempted running a Fedora container on an Ubuntu host running
> > on raw iron?  If not, you need to do so and report those results.
> >
> > I haven't screwed with Xen in years but all HW and para virtualization
> > requires some instruction emulation back in the hypervisor.  This could
> > easily be some incompatibility between the Xen hypervisor in supervisory
> > state and emulating some instruction that systemd is requiring.  I can't
> > even begin to reproduce your environment at this point with Xen in the
> > loop.  You really need to simplify this into a basic install with basic
> > containers and try running it that way.  This could be a problem in the
> > Xen hypervisor, it could be a problem in the Xen guest virt drivers, it
> > could be in systemd that never expected to run in a container in a guest
> > under Xen.  I can't tell.
> >
> > In the upcoming week, I'll look into firing up an Ubuntu server, since I
> > now have a free Dell tower now that I've virtualized my NST development
> > engines into LXC containers.  I don't even want to THINK about doing
> > Xen.
> >
> > You've got to simplify that environment in order to isolate the origin
> > of the problem.
> >

> I took a try at this earlier and it worked fine.

So, you're saying that it worked without Xen virtualization and failed
with Xen virtualization?  That would be a clue.

> I did a full install
> and boot for Fedora 20 amd64 using "lxc-create -t download -n test" as
> root.  Here is my environment.

> Host: Linode
> Kernel: 3.14.3 (host supplied)
> Technology: Xen Paravirtualized

> Xen Hypervisor Mode (HVM) shouldn't be much different than KVM however
> I have not used each of them enough to know for sure.

I have had some experience with writing hypervisors and instruction
emulation in the past and I will tell you that each implementation will
have it's own problems.  Xen or LKVM or VMWare or VirtualBox, in a
situation like this you have to validate the configuration without the
HW virtualization to insure that it hasn't injected some problem through
those supervisory state emulations.

LXC has nothing do to with LKVM.  You've also tested this under LKVM?
And your results of that where?  That would be a third point on the
curve.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140524/c75fcf82/attachment.sig>