On Tue, May 31, 2016 at 6:08 PM, Kurt Lidl <l...@pix.net> wrote:
> What isn't really explained in so many words -- the container uses the
> system calls from the hosting computer to evaluate anything that it
> needs the "kernel" to do. So your "FreeBSD docker" image, when run on
> a Linux machine, is attempting to make FreeBSD system calls into the
> Linux kernel.
> You'd have to use some other solution to provide a "FreeBSD system call
> interface" to your FreeBSD docker image.
> The recent import of Linux 64bit emulation in FreeBSD allows for running
> stock "docker" images on FreeBSD, because there's now a shim that
> translates Linux system calls to FreeBSD ones.
> On the Mac, they have shims that provide filesystem access to the Mac's
> filesystems, and a virtualized machine using the xhyve stuff, providing
> the Linux system call interface.
> Make no mistake about, docker is Linux inside.
> If you want to run FreeBSD inside a virtual machine, try the xhyve stuff
> on the Mac, or under KVM on Linux.
Ah, now I get it. I didn't realize that system calls were the
interface between the docker images in a container and the host. But
that definitely explains why the FreeBSD images won't work apart from
a FreeBSD host.
So it looks like, if I'm committed to docker, I could run FreeBSD
inside a KVM inside a container on Linux. Then others who might be
interested in FreeBSD could play around with it on their Linux hosts
And I suppose, since I need to mount a volume, I'd need to mount it
both into the docker container and, from there, through KVM to
FreeBSD. Not fun, but plausible at least.
Thanks very much for the explanation, Kurt!
Jeff Terrell, Ph.D. | Chief Technology Officer
(919) 357-3116 | www.altometrics.com
email@example.com mailing list
To unsubscribe, send any mail to