github/linuxkit
1
0
Fork 0
mirror of https://github.com/linuxkit/linuxkit.git synced 2025-07-21 10:09:07 +00:00
Code Issues Projects Releases Wiki Activity
A toolkit for building secure, portable and lean operating systems for containers
2,277 Commits 1 Branch 27 Tags 240 MiB
Go 47.8%
text 21.7%
Shell 13.7%
Dockerfile 5.8%
OCaml 4.7%
Other 6.3%
0dbb1e6e97
Go to file
Ian Campbell 0dbb1e6e97 qemu: Enable KVM support and switch to Q35 
Passing accel=kvm:tcg causes it to try KVM first if available with a fallback
to TCG (emulated/JIT mode) if it is not available. With this the boot logs gain:

+Hypervisor detected: KVM

and also

-Booting paravirtualized kernel on bare hardware
+Booting paravirtualized kernel on KVM

Among various other noise.

If I rename my host /dev/kvm then this is reversed, although with the following
message:

  Could not access KVM kernel module: No such file or directory
  failed to initialize KVM: No such file or directory
  Back to tcg accelerator.

Q35 is a more modern emulated platform based on the ICH9 host chipset rather
than the default "pc" I440FX (Pentium Pro / Pentium II era) emulation. See
http://wiki.qemu-project.org/Features/Q35 for more info. Switching to Q35 is
not a requirement for enabling KVM but seemed like a reasonable change.

Signed-off-by: Ian Campbell <ian.campbell@docker.com>
2017-03-13 15:39:08 +00:00
base Fix build of Docker container 2017-03-13 11:32:37 +00:00
docs docs: Update kernel patches documentation 2017-03-07 19:42:23 +00:00
ebpf
kernel kernel: Update to 4.9.14/4.4.53 2017-03-13 10:26:28 +00:00
pkg Out with the old, in with the new Moby 2017-03-06 22:28:41 +00:00
reports reports: nit typo fixes 2017-03-13 10:23:21 +00:00
scripts qemu: Enable KVM support and switch to Q35 2017-03-13 15:39:08 +00:00
tools qemu: Enable KVM support and switch to Q35 2017-03-13 15:39:08 +00:00
vendor Rough first version of the moby tool 2017-02-20 21:44:23 +00:00
.datakitci.json Out with the old, in with the new Moby 2017-03-06 22:28:41 +00:00
.gitignore Add qcow2 output support 2017-03-10 16:38:37 +00:00
config.go hoist kernel cmdline into moby.yaml 2017-03-09 14:29:40 -08:00
main.go better debugging output in more error cases 2017-03-09 14:29:40 -08:00
Makefile Merge pull request #1264 from tych0/hoist-kernel-cmdline 2017-03-09 22:34:30 +00:00
moby.yaml kernel: Update yaml files to latest kernel 2017-03-13 11:25:39 +00:00
output.go Add qcow2 output support 2017-03-10 16:38:37 +00:00
README.md docs: update README formatting and some additional info 2017-03-13 10:46:58 +00:00
test.yaml kernel: Update yaml files to latest kernel 2017-03-13 11:25:39 +00:00
vendor.conf Rough first version of the moby tool 2017-02-20 21:44:23 +00:00

README.md

Moby

Moby, a toolkit for custom Linux distributions

Getting Started

Build

Simple build instructions: use make to build. This will build the Moby customisation tool and a Moby initrd image.

Requirements:

  • GNU make
  • GNU or BSD tar (not Busybox tar)
  • Docker

Booting and Testing

  • make qemu will boot up a sample Moby in qemu in a container
  • on OSX: make hyperkit will boot up Moby in hyperkit, and also download hyperkit and vpnkit binaries for later use
  • make test or make hyperkit-test will run the test suite

Customise

To customise, copy or modify the moby.yaml to your own file.yaml and then run ./bin/moby file.yaml to generate its specified output. You can run the output with ./scripts/qemu.sh or ./scripts/hyperkit.sh.

Yaml Specification

The Yaml format is loosely based on Docker Compose:

  • kernel specifies a kernel Docker image, containing a kernel and a filesystem tarball, eg containing modules. mobylinux/kernel is built from kernel/
  • init is the base init process Docker image, which is unpacked as the base system, containing init, containerd, runc and a few tools. Built from base/init/
  • system are the system containers, executed sequentially in order. They should terminate quickly when done.
  • daemon is the system daemons, which normally run for the whole time
  • files are additional files to add to the image
  • outputs are descriptions of what to build, such as ISOs.

For the images, you can specify the configuration much like Compose, with some changes, eg capabilities must be specified in full, rather than add and drop, and there are no volumes only binds.

The config is liable to be changed, eg there are missing features (specification of kernel command line, more options etc).