By default we want qemu to use the EFI firmware image in the qemu
container. However the logic in the code would always bind mount
the FW image into the container.
This commit changes the logic to only bind mount the FW image if
it was specified on the commandline.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This follows the model in the hyperkit runner, although the options are
different.
The options are:
- `user`: the existing user mode networking (the default).
- `tap,«device»`: replaces the previous `-tap-device «device»` option.
- `bridge,«name»`: tap device on (preexisting) named bridge.
- `none`: No networking at all.
If not running as root then `bridge` mode requires host configuration
http://wiki.qemu.org/Features/HelperNetworking. TL;DR: you need to `chmod u+s`
the `qemu-bridge-helper` and to whitelist specific bridges in
`/etc/qemu/bridge.conf`.
Pass an explicit virtio nic and configure a random MAC since QEMU seems to use
the same one by default.
In the hyperkit runner the various `networking*` constants become
`hyperkitNetworking*` to avoid namespace clashes (e.g. for `None`). The QEMU
equivalents are `qemuNetworking*`.
Both hyperkit and qemu now support an explicit `-networking default` or
`-networking ''` to make scripting easier.
Signed-off-by: Ian Campbell <ijc@docker.com>
This is the same behaviour as the LinuxKit backend.
This populates /sys/class/dmi/id/product_uuid, which newer version of weave-net
appears to require.
Signed-off-by: Ian Campbell <ijc@docker.com>
This commit refactors the OpenStack push support to make use of the
Gophercloud library in order to handle authentication and talking to the
right image service as defined in the service catalogue.
Signed-off-by: Nick Jones <nick@dischord.org>
The motivation for this is networking out (in particular, testing NFS
support) from the VM.
We could be a lot more user friendly (a la libvirt) by creating the tap
device for users and allowing them to specify a bridge instead, but then
we'd need root to create this tap device. For now, let's make people do
their own tap devices, and just use them. A tap device can be created for a
bridge as follows:
# ip tuntap add linuxkit0 mode tap user `whoami`
# ip link set linuxkit0 up
# ip link set linuxkit0 master $bridge_name
and then used by:
$ ./bin/linuxkit run qemu -tap-device linuxkit0 linuxkit
Signed-off-by: Tycho Andersen <tycho@docker.com>
Current implementation uses a fixed firmware(bios) binary
installed by the build process of the qemu container image,
which will prevent us from providing an external firmware binary
outside the container. This patch removes this limitation, thus we
can assign a firware binary image file with "-fw" option.
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
This is useful in the case where Moby is shelling out to LinuxKit for certain
image types (currently raw and qcow2). Currently to experiment with different
options (e.g. when comparing performance to CI) you have to edit either the
moby or linuxkit tool to change the options used.
The environment variables take precedence over any explict command line options
given.
Signed-off-by: Ian Campbell <ijc@docker.com>
This commit fixes an issue reported on Slack where `linuxkit run` will
assume that a file that is neither a kernel or iso must be a disk image
without first checking that it exists. This would result in `qemu-img`
attempting to create a disk with 0 size due to the default behaviour of
creating disk images that do not exist.
Signed-off-by: Dave Tucker <dt@docker.com>
Latest `vndr` has changed its algorithm a bit. It also pointed out that we were missing
some things.
Move the `vendor` directory up to the `linuxkit` command, else it gets confused by packages
that have Go code in.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Current implementation hardcodes the virtual machine as
"q35" for x86, this patch remove this hardcode and config
the machine type according to the arch the VM is running.
Also, in order to make sure the qemu can run on arm64 platform,
we need to specify the vcpu type in the command line.
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
The default is set by probing for /dev/kvm. Use of KVM can be forcibly disabled
with `-enable-kvm=false`. Note that passing `-enable-kvm=true` when `/dev/kvm` is
not present still boots but complains:
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Allows routed networking, so long as you runhyperkit as root.
This has quite a few downsides, including the requirement to
run as root in order to set up the networking, but some people
really want VMs that are routable from the host.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- Use 'flags' for the subcommand FlagSet
- Use %v to print errors
- Use 'path' for the path
- Fix cases where the 'path' refers to a different directory
- Don't use CamelCase for command line options
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Based on the hyperkit runner's code.
project/kubernetes/boot.sh now works, although lack of network connectivity
between individual VMs remains an issue.
Also manually validated containerized operation with:
rm -rf kube-node-0-state && ../../bin/linuxkit run qemu --containerized -cpus 2 -mem 4096 -state kube-node-0-state -disk size=4G -data "foo bar" kube-node
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Modelled on the Hyperkit runner, for now only used for the disk.
This is one step closer to having project/kubernetes/boot.sh work on Linux.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
The Hyper-V backend is loosly based on the docker-machine code
as well as ./scripts/LinuxKit.ps1. It shells out to Powershell
for most of the configuration.
Console is provided by github.com/Azure/go-ansiterm/winterm
and the ode surrounding it is loosely based on the equivalent
code in containerd and moby/moby.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
commit bdf9b1f31a introduced a bug with disk size handling
where GB was not handled correctly. Fix it.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Most cloud providers allow disk size allocation on in units
of GB. Make it the default for linuxkit disk "size" arguments.
Users can override the unit by appending a M to the disk size.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This makes it easier to identify where a new backend should be added.
It's also simpler to match help text and case statements.
Signed-off-by: Dave Tucker <dt@docker.com>
- no longer uses several of the `mkimage-*` tools in favour of dogfooding
with `linuxkit` and using the `mkimage` package.
- fix the qemu docker container fallbacks to work better when multiple
paths are used for disks and the image.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
azure: React to change requests
azure: Fix push and run message and update example
azure: Remove docker dependency and upload VHD
Modify %s to %v for Go errors
Signed-off-by: radu-matei <matei.radu94@gmail.com>
This changes the CLI specification for disks, as it needs to be able to
be repeated.
```
linuxkit run qemu -disk name,size=1G,format=qcow2 ...
```
Options may be omitted.
Currently other local backends may not support multiple disks, but this
can be added in future. Code for cloud backends has not changed as the
disk support is specific to the platform.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
