Extra groups were not being handled when exec'ing. Ensure
that these are handled.
Before this, running a pod with:
```
...snippet...
securityContext:
fsGroup: 266
runAsGroup: 51020
runAsUser: 264
```
And then exec'ing would not supply the fsGroup:
```
$ kubectl exec -it kata-bb -- sh -c id
uid=264 gid=51020
```
Fixes: #1500
Signed-off-by: Eric Ernst <eric.g.ernst@gmail.com>
Each Kata Containers application should generate log records with a specified
structure. Currently on containerd-shim-v2's logs, the required 'name' field
is missing. This changed its logger to append the application name on each
and every emitted entries.
Fixes#1479
Related-to: github.com/kata-containers/tests/issues/3260
Suggested-by: James O. D. Hunt <james.o.hunt@intel.com>
Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Looks like we inadvertantly removed the check on the loadRuntimeConfig
error return value. Adding back...
Fixes: #1474
Signed-off-by: Eric Ernst <eric.g.ernst@gmail.com>
Since the kata's hypervisor process is in the network namespace,
which is close to container's process, and some host metrics
such as cadvisor can use this pid to access the network namespace
to get some network metrics. Thus this commit replace the shim's
pid with the hypervisor's pid.
Fixes: #1451
Signed-off-by: fupan.lfp <fupan.lfp@antfin.com>
There's no more NEMU, for some time already. Considering this, let's
just remove any mention to it as part of our project.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
There's no reason to ship qemu & qemu-virtiofs when the former already
includes vitiofs support (and that's the default for 2.x deployments).
In case we will enable experimental qemu DAX support, we should add a
new target, a "qemu-experimental" target, as Carlos has been working on.
Fixes: #1424
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
VhostUserDeviceAttrs::PCIAddr didn't actually store a PCI address
(DDDD:BB:DD.F), but rather a PCI path. Use the PciPath type and
rename things to make that clearer.
TestHandleBlockVolume previously used the bizarre value "0001:01"
which is neither a PCI address nor a PCI path for this value. Change
it to a valid PCI path - it appears the actual value didn't matter for
that test, as long as it was consistent.
Forward port of
3596058c67fixes#1040
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
BlockDrive::PCIAddr doesn't actually store a PCI address
(DDDD:BB:DD.F) but a PCI path. Use the PciPath type and rename things
to make that clearer.
TestHandleBlockVolume() previously used a bizarre value "0002:01" for
the "PCI address" which was neither an actual PCI address, nor a PCI
path. Update it to use a PCI path - the actual value appears not to
matter in this test, as long as its consistent throughout.
Forward port of
64751f377bfixes#1040
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The "PCI address" returned by Endpoint::PciPath() isn't actually a PCI
address (DDDD:BB:DD.F), but rather a PCI path. Rename and use the
PciPath type to clean this up and the various parts of the network
code connected to it.
Forward port of
3e589713cffixes#1040
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Now that we have types to represent PCI paths on both the agent and
runtime sides, we can update the protocol definitionto use clearer
terminology.
Note that this doesn't actually change the agent protocol, because it just
renames a field without changing its field ID or type.
While we're there fix a trivial rustfmt error in
src/agent/protocols/build.rs
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This is a dedicated data type for representing PCI paths, that is, PCI
devices described by the slot numbers of the bridges we need to reach
them.
There are a number of places that uses strings with that structure for
things. The plan is to use this data type to consolidate their
handling. These are essentially Go equivalents of the pci::Slot and
pci::Path types introduced in the Rust agent.
Forward port of
185b3ab044
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Remove loading of configuration from New() because we do not know the
correct configuration file for the runtime until Create() and so that it
is not loaded more than once. Start tracer in create() so that it is
created after the runtime config is loaded in its original location.
Fixes#1411
Signed-off-by: Chelsea Mafrica <chelsea.e.mafrica@intel.com>
Today hooks are only described in the QEMU toml. This shouldn't be VMM
specific -- let's make sure these are advertised for Cloud Hypervisor as
well.
Fixes: #1401
Signed-off-by: Eric Ernst <eric.g.ernst@gmail.com>
Today we only clear out the cpuset details when doing an update call on
existing container/pods. This works in the case of Kubernetes, but not
in the case where we are explicitly setting the cpuset details at boot
time. For example, if you are running a single container via docker ala:
docker run --cpuset-cpus 0-3 -it alpine sh
What would happen is the cpuset info would be passed in with the
container spec for create container request to the agent. At that point
in time, there'd only be the defualt number of CPUs available in the
guest (1), so you'd be left with cpusets set to 0. Next, we'd hotplug
the vCPUs, providing 0-4 CPUs in the guest, but the cpuset would never
be updated, leaving the application tied to CPU 0.
Ouch.
Until the day we support cpusets in the guest, let's make sure that we
start off clearing the cpuset fields.
Fixes: #1405
Signed-off-by: Eric Ernst <eric.g.ernst@gmail.com>
Remove the old config options from the documentation and replace them
with the new form (without the redundant `kata-` prefix).
Signed-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com>
Remove `kata-` prefix from options `kata-config` and
`kata-show-default-config-paths`.
Fixes#1011
Signed-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com>
add configuration items in Kata Containers
configuration file to let users specify jaeger
collector address, and user/password.
Signed-off-by: bin <bin@hyper.sh>
This commit includes two changes:
- migrate from opentracing to opentelemetry
- add jaeger configuration items
Fixes: #1351
Signed-off-by: bin <bin@hyper.sh>
CGO_ENABLED=0 and -buildmode=pie are not compatible and may lead build failing in some OS.
Specify buildmode=exe to overwrite the value set in BUILDFLAGS
Fixes: #1343
Signed-off-by: bin <bin@hyper.sh>
acpi is enabled for kata 1.x, port and rebase code for 2.x
including:
runtime: enable pflash;
agent: add acpi support for pci bus path;
packaging: enable CONFIG_RTC_DRV_EFI;
Fixes: #1317
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Highlights for cloud-hypervisor version v0.12.0 include: removal of
`vhost-user-net` and `vhost-user-block` self spawning, migration of
`vhost-user-fs` backend, ARM64 enhancements with full support of
`--watchdog` for rebooting, and enhanced `info` HTTP API to include the
details of devices used by the VM including VFIO devices.
Fixes: #1315
Signed-off-by: Bo Chen <chen.bo@intel.com>
According to runtime-spec:
The poststart hooks MUST be invoked by the runtime. If any poststart
hook fails, the runtime MUST log a warning, but the remaining hooks
and lifecycle continue as if the hook had succeeded
Fixes: #1252
Signed-off-by: Snir Sheriber <ssheribe@redhat.com>
According to runtime-spec:
The poststop hooks MUST be invoked by the runtime. If any
poststop hook fails, the runtime MUST log a warning, but
the remaining hooks and lifecycle continue as if the hook
had succeeded.
Fixes: #1252
Signed-off-by: Snir Sheriber <ssheribe@redhat.com>
Qemu config alredy use vanilla kernel build for virtiofs.
Lets make cosisntent the usage of kernel.
Depends-on: github.com/kata-containers/tests#3172
Fixes: #1302
Signed-off-by: Carlos Venegas <jos.c.venegas.munoz@intel.com>
Run static checks prior to building the agent.Checks
fail if run after since the compilation process
produces new rust code.
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
RemoveContainerRequest results in calling to deleteContainer, according
to spec calling to RemoveContainer is idempotent and "must not return
an error if the container has already been removed", hence, don't
return error if the error reports that the container is not found.
Fixes: #836
Signed-off-by: Snir Sheriber <ssheribe@redhat.com>
On pod delete, we were looking to read files that we had just deleted. In particular,
stopSandbox for QEMU was called (we cleanup up vmpath), and then QEMU's
save function was called, which immediately checks for the PID file.
Let's only update the persist store for QEMU if QEMU is actually
running. This'll avoid Error messages being displayed when we are
stopping and deleting a sandbox:
```
level=error msg="Could not read qemu pid file"
```
I reviewed CLH, and it looks like it is already taking appropriate
action, so no changes needed.
Ideally we won't spend much time saving state to persist.json unless
there's an actual error during stop/delete/shutdown path, as the persist will
also be removed after the pod is removed. We may want to optimize this,
as currently we are doing a persist store when deleting each container
(after the sandbox is stopped, VM is killed), and when we stop the sandbox.
This'll require more rework... tracked in:
https://github.com/kata-containers/kata-containers/issues/1181Fixes: #1179
Signed-off-by: Eric Ernst <eric.g.ernst@gmail.com>
