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

[Stéphane Graber]

On Tue, Apr 01, 2014 at 07:43:32PM -0400, Michael H. Warfield wrote:
> 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?

Hmm, aren't we already doing that?

stgraber at castiana:~$ uname -m
x86_64

stgraber at castiana:~$ lxc-create -t download -n i386 -- -d ubuntu -r trusty -a i386
Using image from local cache
Unpacking the rootfs

---
You just created an Ubuntu container (release=trusty, arch=i386, variant=default)
The default username/password is: ubuntu / ubuntu
To gain root privileges, please use sudo.

stgraber at castiana:~$ lxc-start -n i386 -d

stgraber at castiana:~$ lxc-attach -n i386 -- uname -m
i686

stgraber at castiana:~$ lxc-stop -n i386 -k
stgraber at castiana:~$ grep arch .local/share/lxc/i386/config 
lxc.arch = x86



lxc.arch lets you override the personality, we currently only support
x86 personalities (we probably should look into the armhf/arm64 ones at
some point).

The download template and I believe a few others will set lxc.arch
properly by default, so you only need to use setarch for commands
running during container creation.

> 
> 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!
> 



> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20140401/4172da49/attachment.pgp>