[lxc-devel] Cross arch container thoughts - Call for Discussion...

[Michael H. Warfield]

So...

Some may have read an earlier message I wrote primarily to the NST
(Network Security Toolkit) crowd but cc'ed to this list about building
their ISO images in an LXC container.  That seems to work pretty well
for the like-on-like case (x86_64 container on x86_64 host).

The cross arch case (i686 container on x86_64 host) has been beating the
crap out of me for days when I seem to stumble onto the simple answer.
An i686 container running on an x86_64 host still reports x86_64 from
the arch (uname -m) command and related commands.  This causes all sorts
of problems when you're running cross-arch.  The answer would seem to be
in the "setarch" command.  Starting an i686 container by just running
"lxc-start" and arch returns "x86_64".  But...  Starting it by running
"setarch i686 lxc-start -n ${Container}" and arch returns "i686" and my
tasks seem to be working properly now.

My question is this...  If we are going to support "cross arch"
containers, should we not be incorporating "setarch" into the startup of
those containers?  Maybe define an arch type on startup?  If it's set
and is not equally to the basearch, then run setarch?  That way, LXC
could "fake" the container arch.

That isn't quite as simple as it sounds.  For lxc-autostart, it could be
just an arch parameter in the config file and incorporate the command
before firing up the container when arch doesn't match our basearch.
It's a little more complicated for just lxc-start and I have no idea how
that would be incorporated into lxc-execute.

I seem to have solved my "problem" with building NST i686 images in an
LXC i686 container on an x86_64 host but seem to have stumbled onto a
bit of a can of worms here...  Yes, LXC can fake out the arch for a
container (where reasonable).  Should we?  How should we?

Thoughts?

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-devel/attachments/20140401/ecf69229/attachment.pgp>