Add GPU annotations for remote hypervisor to help
with the right instance selection based on number of GPUs
and model
Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
As we don't have any CI, nor maintainer to keep ACRN code around, we
better have it removed than give users the expectation that it should or
would work at some point.
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
This commit add a row for `cdh_api_timeout` to the agent options in
how-to-set-sandbox-config-kata.md.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
First of all, this is a controversial piece, and I know that.
In this commit we're trying to make a less greedy approach regards the
amount of vCPUs we allocate for the VMM, which will be advantageous
mainly when using the `static_sandbox_resource_mgmt` feature, which is
used by the confidential guests.
The current approach we have basically does:
* Gets the amount of vCPUs set in the config (an integer)
* Gets the amount of vCPUs set as limit (an integer)
* Sum those up
* Starts / Updates the VMM to use that total amount of vCPUs
The fact we're dealing with integers is logical, as we cannot request
500m vCPUs to the VMMs. However, it leads us to, in several cases, be
wasting one vCPU.
Let's take the example that we know the VMM requires 500m vCPUs to be
running, and the workload sets 250m vCPUs as a resource limit.
In that case, we'd do:
* Gets the amount of vCPUs set in the config: 1
* Gets the amount of vCPUs set as limit: ceil(0.25)
* 1 + ceil(0.25) = 1 + 1 = 2 vCPUs
* Starts / Updates the VMM to use 2 vCPUs
With the logic changed here, what we're doing is considering everything
as float till just before we start / update the VMM. So, the flow
describe above would be:
* Gets the amount of vCPUs set in the config: 0.5
* Gets the amount of vCPUs set as limit: 0.25
* ceil(0.5 + 0.25) = 1 vCPUs
* Starts / Updates the VMM to use 1 vCPUs
In the way I've written this patch we introduce zero regressions, as
the default values set are still the same, and those will only be
changed for the TEE use cases (although I can see firecracker, or any
other user of `static_sandbox_resource_mgmt=true` taking advantage of
this).
There's, though, an implicit assumption in this patch that we'd need to
make explicit, and that's that the default_vcpus / default_memory is the
amount of vcpus / memory required by the VMM, and absolutely nothing
else. Also, the amount set there should be reflected in the
podOverhead for the specific runtime class.
One other possible approach, which I am not that much in favour of
taking as I think it's **less clear**, is that we could actually get the
podOverhead amount, subtract it from the default_vcpus (treating the
result as a float), then sum up what the user set as limit (as a float),
and finally ceil the result. It could work, but IMHO this is **less
clear**, and **less explicit** on what we're actually doing, and how the
default_vcpus / default_memory should be used.
Fixes: #6909
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
firmware can be split into FIRMWARE_VARS.fd (UEFI variables as
configuration) and FIRMWARE_CODE.fd (UEFI program image). UEFI
variables can be customized per each user while UEFI code is kept same.
fixes#3583
Signed-off-by: Julio Montes <julio.montes@intel.com>
`enable_swap` option was added long time ago to add
`-realtime mlock=off` to the QEMU's command line.
Kata now supports QEMU 6, `-realtime` option has been deprecated and
`mlock=on` is causing unexpected behaviors in kata.
This patch removes support for `enable_swap`, `-realtime` and `mlock=`
since they are causing bugs in kata.
Signed-off-by: Julio Montes <julio.montes@intel.com>
Now enabling enable_pprof for individual pods is supported,
but not documented.
This commit will add per-Pod Kata configurations for `enable_pprof`
in file `docs/how-to/how-to-set-sandbox-config-kata.md`
Fixes: #1744
Signed-off-by: bin <bin@hyper.sh>
It would be undesirable to be given an annotation like "/dev/null".
Filter out bad annotation values.
Fixes: #1043
Suggested-by: James O. D. Hunt <james.o.hunt@intel.com>
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
The documentation contains existing spelling mistakes that are caught by the CI
and prevent checking in. The errors include:
INFO: Spell checking file 'docs/how-to/how-to-load-kernel-modules-with-kata.md'
WARNING: Word 'configurated': did you mean one of the following?: configuration, reconfigured, Confederate, confederate
WARNING: Word 'cri': did you mean one of the following?: cir, crib, chi, cry, Fri, crier
ERROR: Spell check failed for file: 'docs/how-to/how-to-load-kernel-modules-with-kata.md'
INFO: spell check failed for document docs/how-to/how-to-load-kernel-modules-with-kata.md
INFO: Spell checking file 'docs/how-to/how-to-set-sandbox-config-kata.md'
INFO: Spell check successful for file: 'docs/how-to/how-to-set-sandbox-config-kata.md'
ERROR: spell check failed, See https://github.com/kata-containers/documentation/blob/master/Documentation-Requirements.md#spelling for more information.
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
The documentation `how-to/how-to-set-sandbox-config-kata.md` contains a number
of differences relative to the 1.x variant, which do not seem to correspond to
missing features in the actual code.
Fixes: #1046
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Using pod annotations requires a minimum version of v1.3.0 of containerd
to pass annotations down to kata. This is already somewhat mentioned in
the corresponding how-to, however, it can be mis-read as the minimum
version of kata-containers instead of containerd. This can cause
extended and futile troubleshooting on older distributions such as
Ubuntu 16.04 which ship a version of 1.2.x of containerd. This patch
attempts to clarify this.
Fixes: #690
Signed-off-by: Georg Kunz <georg.kunz@est.tech>
