In order to move the hypervisor implementations into their own package,
we need to put the capabilities type into the types package.
Fixes: #1119
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In order to move the hypervisor implementations into their own package,
we need to put the asset type into the types package and break the
hypervisor->asset->virtcontainers->hypervisor cyclic dependency.
Fixes: #1119
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Support building with `make HYPERVISOR=firecracker`.
Notes:
- Firecracker is currently only supported on x86_64, hence the
architecture check.
- The template file `cli/config/configuration-fc.toml.in` is based
on `cli/config/configuration.toml.in`.
Fixes#1105.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Improve the build to:
- Encapsulate the qemu configuration.
- Validate the chosen hypervisor.
- Display hypervisor details for `make help`.
This lays the groundwork to build configurations for multiple
hypervisors.
Notes:
- Variables that are hypervisor specific have now been suffixed with `_QEMU`.
- `make install` now installs `configuration-qemu.toml`.
To maintain compatibility with existing installations, a symbolic link
to this file called `configuration.toml` is created.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
In some build systems like launchpad is not possible to run neither
custom commands or hooks, hence build a snap image with `make snap` is
not feasible, to deal with this limitation, the final snapcraft.yaml
is part of the repository and all packages versions are read from versions.yaml
in the runtime repository.
fixes#305
Signed-off-by: Julio Montes <julio.montes@intel.com>
Move the quiet prefix from the `INSTALL_EXEC` recipe and use it at the
call sites. This makes the code robust when calling the recipe in a
`$(foreach ...)` loop.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
The error message does not provide the max memory that is exceeded.
Fix it for better error information.
Fixes: #1120
Signed-off-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>
Remove the `network connect` limitation from `Limitations.md` as the limitation has been removed.
Fixes#287.
Signed-off-by: Ayoub Bousselmi <abousselmi@users.noreply.github.com>
Remove the `ps` limitation from `Limitations.md` as the limitation has been removed.
Fixes#342.
Signed-off-by: Ayoub Bousselmi <abousselmi@users.noreply.github.com>
Function SetKernelParams is just to update the runtimeConfig according to itself.
It just around the configuration.
So this patch moves it to updateRuntimeConfig.
Fixes: #1106
Signed-off-by: Hui Zhu <teawater@hyper.sh>
Add firecracker version to versions.yaml. This allows kata
packaging to build and package firecracker.
Fixes: #1103
Signed-off-by: Manohar Castelino <manohar.r.castelino@intel.com>
The contents of /proc/cpuinfo were
trimmed and hence the "model" field could
not be parsed despite being a field in
/proc/cpuinfo. Fix this issue.
Fixes: #1089
Signed-off-by: Nitesh Konkar niteshkonkar@in.ibm.com
This reverts commit 802bfa26c9.
Seems that we have some performance issues when
using this new kernel. Reverting to have a clean CI and
have a proper investigation about the degradation.
Fixes: #1100.
Signed-off-by: Salvador Fuentes salvador.fuentes@intel.com
If the runtime repository is already cloned get version from it,
else keep getting from github.
Fixes: #299
Signed-off-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>
When overlay is used as storage driver, kata runtime creates a new bind mount
point to the merged directory, that way this directory can be shared with the
VM through 9p. By default the mount propagation is shared, that means mount
events are propagated, but umount events not, to deal with this problem and to
avoid left mount points in the host once container finishes, the mount
propagation of bind mounts should be set to private.
Depends-on: github.com/kata-containers/tests#971
fixes#794
Signed-off-by: Julio Montes <julio.montes@intel.com>
And add some additional log output for displaying the directories and
files created when kicking the virtcontainers tests.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
We always call waitSandbox after we start the VM (startSandbox), so
let's simplify the hypervisor interface and integrate waiting for the VM
into startSandbox.
This makes startSandbox a blocking call, but that is practically the
case today.
Fixes: #1009
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
We always combine the hypervisor init and createSandbox, because what
we're trying to do is simply that: Set the hypervisor and have it create
a sandbox.
Instead of keeping a method with vague semantics, remove init and
integrate the actual hypervisor setup phase into the createSandbox one.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
We can now remove all the sandbox shared types and convert the rest of
the code to using the new internal types package.
This commit includes virtcontainers, cli and containerd-shim changes in
one atomic change in order to not break bisect'ibility.
Fixes: #1095
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The types package holds all shared virtcontainers types.
With the separation of the virtcontainers code into separate packages,
we need a types one to not create circular dependencies.
This package holds sandbox related types and structures for now. It will
grow as virtcontainers code is moved into their own internal packages.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Since we're going to have both external and internal types packages, we
alias the external one as vcTypes. And the internal one will be usable
through the types namespace.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Pass Seccomp profile to the agent only if
the configuration.toml allows it to be passed
and the agent/image is seccomp capable.
Fixes: #688
Signed-off-by: Nitesh Konkar niteshkonkar@in.ibm.com
cri containerd calls kill on stopped sandbox and if we
fail the call, it can cause `cri stopp` command to fail
too.
Fixes: #1084
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Now that stopVM() also calls agent.stopSandbox(), we can have the
sandbox Stop() call using stopVM() directly and avoid code duplication.
Fixes: #1011
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
We always ask the agent to start the sandbox when we start the VM, so we
should simply call agent.startSandbox from startVM instead of open
coding those.
This slightly simplifies the complex createSandboxFromConfig routine.
Fixes: #1011
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
