-
Notifications
You must be signed in to change notification settings - Fork 304
Conversation
3bc78ec
to
7c27eb7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @jodh-intel for fixing this, I can't run kata containers with podman, any thoughts? thanks again
Hi @devimc - agreed: it appears to be broken hence the |
@jodh-intel don't worry, I'll take a look too |
@jodh-intel fixed network issue, you have to update podman and slirp4netns. podman version 1.6.2-dev but now I get the following error:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Scrubbed for grammar, spelling, and voice. A few suggestions. Thanks!
| ----------------|:-------:|---------------------| | ||
| Podman | WIP | [see here](https://github.com/containers/libpod/blob/master/install.md) | ||
| `slirp4netns` | 0.4.0 | [see here](https://github.com/rootless-containers/slirp4netns#quick-start) | ||
| Kata Containers | WIP | [see here](https://github.com/kata-containers/documentation/blob/master/install/README.md) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On these three, you might want to be more specific on the link descriptions (just a suggestion) Example:
see the libpod installation instructions
see the quick start
see the Kata Containers installation guides
Or, whatever description makes the most sense.
|
||
If SELinux is installed and enabled, it needs to be disabled with the | ||
following command (Kata Containers | ||
[does not support SELinux](https://github.com/kata-containers/documentation/blob/master/Limitations.md#selinux-support)). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lines 69-71 suggested rewrite:
Kata Containers does not support SELinux). If you have installed and enabled SELinux, you need to disable SELinux using the following command:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say "currently does not support SELinux" because I think at some point it probably would.
$ [ -e ~/.config/containers/libpod.conf ] || install -D /usr/share/containers/libpod.conf ~/.config/containers/libpod.conf | ||
``` | ||
|
||
By default the `tmp_dir` in `libpod.conf` is set to `/var/run/libpod`, however |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a comma after "default"
By default, the ....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On my Fedora system this was already set to /run/user/1000
I'd just reword a bit "Check the tmp_dir
in libpod.conf
is set to /run/user/$(id -u)
. If not then change it with the following command.
|
||
## Appendix: Possible Errors | ||
|
||
If you are building from source you might encounter the following errors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a comma after "source"
If you are building from source, you might...
[agent](https://github.com/kata-containers/agent/commit/a78e8cfda627cc350dc9d9ca9b969ebb642030c3) | ||
and | ||
[runtime](https://github.com/kata-containers/runtime/commit/cfedb06a19135e2ab4f18203a4f3147cdc3a4980) | ||
code. This would probably only occur if building latest from source, since the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested rewrite:
This typically only occurs if building...
@jodh-intel I have raised a PR against your repo to include some changes that I came accross while setting up rootless kata with podman : jodh-intel#1 |
2215298
to
ac549d0
Compare
@amshinde - this still fails for me on Ubuntu 18.04: $ podman run --log-level=debug -ti --runtime=/usr/local/bin/kata-runtime busybox
|
@jodh-intel Ahh I think you are using an kernel older than 4.13.0. We should document this limitation until that is merged. Meanwhile can you give this a try on a newer kernel? |
@jodh-intel Thats a bummer, can you post what error you were seing with the newer kernel? |
@amshinde - here you go...
|
@jodh-intel Thanks, I'll try to reproduce this on a Fedora machine today. I have tried this on Ubuntu on two diff Azure instances and could not replicate it. |
@jodh-intel If you have the setup handy, can you let me know if you see this logs in your runs: |
ac549d0
to
afe50cd
Compare
So, I have tried the steps on two different ubuntu instances on Azure cloud as well as a Fedora 30 VM using ccloudvm. Have been able to run a rootless container with Kata with all of them. @jodh-intel The net=none bug is something that needs to be fixed in podman and is not a very interesting case for rootless. As far as I have tested with the specified versions and the latest instructions in here, this should work. I also feel that we should try to minimise any extra steps required for rootless setup. Second, changing the permissions on the kata image. I have changed the instructions slightly to change the group ownership of the image to group Lastly, we do need to disable selinux. This causes issues not only for rootless containers but also for rooted ones. We should evaluate what is required to make Kata work with selinux. @jodh-intel @egernst Can you please review this doc again so that we can merge it? |
> | ||
> If installing Podman with a package manager, there is usually no need to | ||
> install `slirp4netns` separately. | ||
> You will need to install Kata Containers from source today for rootless support. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I installed using kata-deploy using the 1.10.0-alpha1 tag so this is not technically true. You could rephrase to "You will need to install Kata Containers from source today for rootless support, or you could use kata-deploy with a 1.10.0-alpha1 tag."
| ----------------|:-------------:|---------------------| | ||
| Podman | 1.6.2 | [see here](https://github.com/containers/libpod/blob/master/install.md) | ||
| `slirp4netns` | 0.4.0 | [see here](https://github.com/rootless-containers/slirp4netns#quick-start) | ||
| Kata Containers | 1.10.0-alpha1 | [see here](https://github.com/kata-containers/documentation/blob/master/install/README.md) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think listing the supported hypervisors here makes a lot of sense. We know this probably won't work with ACRN but should work with qemu and firecracker right? Maybe list those as two rows. I'm not sure if the version of the hypervisor matters but here is one way to do it.
Kata Containers 1.10.0-alpha1
Qemu Hypervisonr xxxxversion
Firecracker Hypervisor xxxxversion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we have verified this with qemu itself, I have added that to the doc.
|
||
### Add user to KVM group | ||
|
||
If running a KVM based hypervisor, add the user running the workload to the KVM group: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way this was worded was confusing to me because I thought it was asking if I was already in a VM trying to enable this. I'd reword to something like "Currently only KVM based hypervisors for rootless Podman are supported. To enable rootless support, the user running the workload needs to be added to the KVM group"
> | ||
> `kvm` should be the group owning the device node `/dev/kvm` on most distros. | ||
> Make sure permissions on `/dev/kvm` are as shown below: | ||
> ``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My permissions didn't exactly match this and was crw-rw-rw-
I suggest rewording to "Make sure the minimum permissions on /dev/kvm
are shown below"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
Documentation for running Kata Containers with Podman as a non privileged user Fixes: kata-containers#540 Signed-off-by: gabi beyer <[email protected]>
Changes: - Spaced out the document for clarity. - Folded long lines. - Removed unnecessary numbers in section names. - Improved formatting. Signed-off-by: James O. D. Hunt <[email protected]>
Apply the remaining review feedback to the podman doc. Signed-off-by: James O. D. Hunt <[email protected]>
Disabling SELinux should not be undertaken lightly and users should understand the implications before doing so, hence add a warning. Signed-off-by: James O. D. Hunt <[email protected]>
Remove a redundant blank line. Signed-off-by: James O. D. Hunt <[email protected]>
Fix some obvious code errors in the podman doc. Signed-off-by: James O. D. Hunt <[email protected]>
Update required versions for podman and Kata required for running rootless. rootless: Make sure /dev/kvm has group ownership as kvm rootless: Add explanation for var XDG_RUNTIME_DIR Add a note to explicitly check if this variable is set. Signed-off-by: Archana Shinde <[email protected]>
40f452f
to
7ff4418
Compare
@amshinde - I've cleaned up the doc and re-tested with:
... but I still get $ podman run --log-level=debug --runtime=/usr/local/bin/kata-runtime -ti busybox sh
:
DEBU[0000] running conmon: /usr/bin/conmon args="[--api-version 1 -c ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917 -u ee1b59cfd1cf68783d5eab922795b37a0b0b7f903
4e266cab691e4fe62582917 -r /usr/local/bin/kata-runtime -b /home/james/.local/share/containers/storage/overlay-containers/ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917/userda
ta -p /run/user/1000/overlay-containers/ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917/userdata/pidfile -l k8s-file:/home/james/.local/share/containers/storage/overlay-contai
ners/ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917/userdata/ctr.log --exit-dir /run/user/1000/libpod/tmp/exits --socket-dir-path /run/user/1000/libpod/tmp/socket --log-level
debug --syslog -t --conmon-pidfile /run/user/1000/overlay-containers/ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917/userdata/conmon.pid --exit-command /usr/bin/podman --exit
-command-arg --root --exit-command-arg /home/james/.local/share/containers/storage --exit-command-arg --runroot --exit-command-arg /run/user/1000 --exit-command-arg --log-level --exit-command-
arg debug --exit-command-arg --cgroup-manager --exit-command-arg cgroupfs --exit-command-arg --tmpdir --exit-command-arg /run/user/1000/libpod/tmp --exit-command-arg --runtime --exit-command-a
rg /usr/local/bin/kata-runtime --exit-command-arg --storage-driver --exit-command-arg overlay --exit-command-arg --storage-opt --exit-command-arg overlay.mount_program=/bin/fuse-overlayfs --ex
it-command-arg --events-backend --exit-command-arg journald --exit-command-arg container --exit-command-arg cleanup --exit-command-arg ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe6
2582917]"
DEBU[0002] Received: -1
DEBU[0002] Cleaning up container ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917
DEBU[0002] Tearing down network namespace at /run/user/1000/netns/cni-15e74547-ddaa-52f2-071c-b6fdcd9fb19a for container ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917
DEBU[0002] unmounted container "ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917"
DEBU[0002] ExitCode msg: "rpc error: code = internal desc = could not run process: container_linux.go:346: starting container process caused \"process_linux.go:449: container init caused \\\"r
ootfs_linux.go:58: mounting \\\\\\\"/run/user/1000/run/kata-containers/shared/containers/ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917-77ffebc66c56f81e-resolv.conf\\\\\\\" t
o rootfs \\\\\\\"/run/user/1000/run/kata-containers/shared/containers/ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917/rootfs\\\\\\\" at \\\\\\\"/run/user/1000/run/kata-contain
ers/shared/containers/ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917/rootfs/etc/resolv.conf\\\\\\\" caused \\\\\\\"open /run/user/1000/run/kata-containers/shared/containers/e
e1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917/rootfs/etc/resolv.conf: operation not permitted\\\\\\\"\\\"\": oci runtime permission denied error"
ERRO[0002] rpc error: code = Internal desc = Could not run process: container_linux.go:346: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58:
mounting \\\"/run/user/1000/run/kata-containers/shared/containers/ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917-77ffebc66c56f81e-resolv.conf\\\" to rootfs \\\"/run/user/100
0/run/kata-containers/shared/containers/ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266cab691e4fe62582917/rootfs\\\" at \\\"/run/user/1000/run/kata-containers/shared/containers/ee1b59cfd1cf6878
3d5eab922795b37a0b0b7f9034e266cab691e4fe62582917/rootfs/etc/resolv.conf\\\" caused \\\"open /run/user/1000/run/kata-containers/shared/containers/ee1b59cfd1cf68783d5eab922795b37a0b0b7f9034e266c
ab691e4fe62582917/rootfs/etc/resolv.conf: operation not permitted\\\"\"": OCI runtime permission denied error I can't spend any more time on this today but it would be useful to know what results you see atm. |
@jodh-intel Interesting, you are getting a permission denied error while mounting on |
7ff4418
to
2c152b2
Compare
I can create a container on 18.04 using latest runtime but only without networking. With networking gives: $ podman run --log-level=debug --rm --runtime=/usr/local/bin/kata-runtime -ti alpine sh
:
DEBU[0000] running conmon: /usr/bin/conmon args="[--api-version 1 -c eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d -u eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d -r /usr/local/bin/kata-runtime -b /home/james/.local/share/containers/storage/vfs-containers/eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d/userdata -p /run/user/1000/vfs-containers/eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d/userdata/pidfile -l k8s-file:/home/james/.local/share/containers/storage/vfs-containers/eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d/userdata/ctr.log --exit-dir /run/user/1000/libpod/tmp/exits --socket-dir-path /run/user/1000/libpod/tmp/socket --log-level debug --syslog -t --conmon-pidfile /run/user/1000/vfs-containers/eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d/userdata/conmon.pid --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /home/james/.local/share/containers/storage --exit-command-arg --runroot --exit-command-arg /run/user/1000 --exit-command-arg --log-level --exit-command-arg debug --exit-command-arg --cgroup-manager --exit-command-arg cgroupfs --exit-command-arg --tmpdir --exit-command-arg /run/user/1000/libpod/tmp --exit-command-arg --runtime --exit-command-arg /usr/local/bin/kata-runtime --exit-command-arg --storage-driver --exit-command-arg vfs --exit-command-arg --events-backend --exit-command-arg journald --exit-command-arg container --exit-command-arg cleanup --exit-command-arg --rm --exit-command-arg eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d]"
WARN[0000] Failed to add conmon to cgroupfs sandbox cgroup: error creating cgroup for memory: mkdir /sys/fs/cgroup/memory/libpod_parent: permission denied
DEBU[0000] Received: -1
DEBU[0000] Cleaning up container eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d
DEBU[0000] Tearing down network namespace at /run/user/1000/netns/cni-547e148d-9fb4-a148-3d62-0bafb869236a for container eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d
DEBU[0000] unmounted container "eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d"
DEBU[0000] Cleaning up container eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d
DEBU[0000] Network is already cleaned up, skipping...
DEBU[0000] Container eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d storage is already unmounted, skipping...
DEBU[0000] Container eda58c3bd4a21fa8e625026d7a35a7814eaae58fca51dbabce697d08a134a35d storage is already unmounted, skipping...
DEBU[0000] ExitCode msg: "network device mode not determined correctly. mount sysfs in caller: oci runtime error"
ERRO[0000] Network device mode not determined correctly. Mount sysfs in caller: OCI runtime error Attempting the same on F30 fails in all scenarios, even after a $ chmod 777 -R /run/user/1000
$ podman run --log-level=debug --runtime=/usr/local/bin/kata-runtime -ti busybox sh
:
EBU[0000] running conmon: /usr/bin/conmon args="[--api-version 1 -c a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a -u a0d1af0363001f2b2d3fdfc4332a09ea94a708c56
854d752a761a4a6579b176a -r /usr/local/bin/kata-runtime -b /home/james/.local/share/containers/storage/overlay-containers/a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a/userda
ta -p /run/user/1000/overlay-containers/a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a/userdata/pidfile -l k8s-file:/home/james/.local/share/containers/storage/overlay-contai
ners/a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a/userdata/ctr.log --exit-dir /run/user/1000/libpod/tmp/exits --socket-dir-path /run/user/1000/libpod/tmp/socket --log-level
debug --syslog -t --conmon-pidfile /run/user/1000/overlay-containers/a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a/userdata/conmon.pid --exit-command /usr/bin/podman --exit
-command-arg --root --exit-command-arg /home/james/.local/share/containers/storage --exit-command-arg --runroot --exit-command-arg /run/user/1000 --exit-command-arg --log-level --exit-command-
arg debug --exit-command-arg --cgroup-manager --exit-command-arg cgroupfs --exit-command-arg --tmpdir --exit-command-arg /run/user/1000/libpod/tmp --exit-command-arg --runtime --exit-command-a
rg /usr/local/bin/kata-runtime --exit-command-arg --storage-driver --exit-command-arg overlay --exit-command-arg --storage-opt --exit-command-arg overlay.mount_program=/bin/fuse-overlayfs --ex
it-command-arg --events-backend --exit-command-arg journald --exit-command-arg container --exit-command-arg cleanup --exit-command-arg a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a65
79b176a]"
DEBU[0001] Received: -1
DEBU[0001] Cleaning up container a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a
DEBU[0001] Tearing down network namespace at /run/user/1000/netns/cni-60233ed6-2bb6-aca1-3362-d26e46d693de for container a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a
DEBU[0001] unmounted container "a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a"
DEBU[0001] ExitCode msg: "rpc error: code = internal desc = could not run process: container_linux.go:346: starting container process caused \"process_linux.go:449: container init caused \\\"r
ootfs_linux.go:58: mounting \\\\\\\"/run/user/1000/run/kata-containers/shared/containers/a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a-2a39472b6ed3d748-resolv.conf\\\\\\\" t
o rootfs \\\\\\\"/run/user/1000/run/kata-containers/shared/containers/a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a/rootfs\\\\\\\" at \\\\\\\"/run/user/1000/run/kata-contain
ers/shared/containers/a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a/rootfs/etc/resolv.conf\\\\\\\" caused \\\\\\\"open /run/user/1000/run/kata-containers/shared/containers/a
0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a/rootfs/etc/resolv.conf: operation not permitted\\\\\\\"\\\"\": oci runtime permission denied error"
ERRO[0001] rpc error: code = Internal desc = Could not run process: container_linux.go:346: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58:
mounting \\\"/run/user/1000/run/kata-containers/shared/containers/a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a-2a39472b6ed3d748-resolv.conf\\\" to rootfs \\\"/run/user/100
0/run/kata-containers/shared/containers/a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a/rootfs\\\" at \\\"/run/user/1000/run/kata-containers/shared/containers/a0d1af0363001f2b
2d3fdfc4332a09ea94a708c56854d752a761a4a6579b176a/rootfs/etc/resolv.conf\\\" caused \\\"open /run/user/1000/run/kata-containers/shared/containers/a0d1af0363001f2b2d3fdfc4332a09ea94a708c56854d75
2a761a4a6579b176a/rootfs/etc/resolv.conf: operation not permitted\\\"\"": OCI runtime permission denied error @amshinde - looking back over this PR, it appears you've only tested rootless under Azure? If so, please could you try on a baremetal or local VM environment as these are where I see problems. |
- Removed `--enable-man` when building shadow tools. - Corrected invalid command (`addgroup` -> `groupadd`). - Set trusted group to `kvm`. - Added a distro-agnostic check for installing subuid support. - Fixed some bash commands. - Fixed typos and spelling mistakes. - Fixed permissions on files. - Fixed SELinux checks for non-SELinux distros. Signed-off-by: James O. D. Hunt <[email protected]>
2c152b2
to
e38acfe
Compare
@jodh-intel I had tried this on ubuntu 18.04 on azure and on a local Fedora 30 VM using ccloudvm. Using a newer kernel should solve that issue. I am really not sure why you are having issues on Fedora. I would need access to a machine to debug this. Perhaps you can set this up on a machine on company network? |
As an FYI I verified this works on Fedora 30 bare metal and Clear Linux as well. I had to build podman and slirp4netns from source for Clear Linux. I am working with the Clear team to get podman and slirp4netns added to a bundle but it will take some time. |
@amshinde - The original doc (which I'm simply supposed to be updating on this PR btw :) states the host kernel needs to be 4.14+. Bionic uses a 4.15.0-72 kernel so please can you check in a non-cloud environment? |
Progress! I don't know exactly what the problem was, but it related to permissions inside (?) the cached docker images I noticed that the following worked on F30: $ podman run --log-level=debug --runtime=/usr/local/bin/kata-runtime --net=none -ti -rootfs ~/tmp/bundle/rootfs sh I then zapped my images (should have backed these up first, but... ): $ podman rmi -f alpine
$ podman rmi -f busybox ... and I can now run the following (with networking) for example on F30: $ podman run --log-level=debug --runtime=/usr/local/bin/kata-runtime -ti alpine sh However, I still cannot get networking to work on Ubuntu 18.04 (even after zapping the podman images): podman run --log-level=debug --rm --runtime=/usr/local/bin/kata-runtime -ti alpine sh
:
DEBU[0004] /usr/bin/conmon messages will be logged to syslog
DEBU[0004] running conmon: /usr/bin/conmon args="[--api-version 1 -c b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0 -u b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0 -r /usr/local/bin/kata-runtime -b /home/james/.local/share/containers/storage/vfs-containers/b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0/userdata -p /run/user/1000/vfs-containers/b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0/userdata/pidfile -l k8s-file:/home/james/.local/share/containers/storage/vfs-containers/b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0/userdata/ctr.log --exit-dir /run/user/1000/libpod/tmp/exits --socket-dir-path /run/user/1000/libpod/tmp/socket --log-level debug --syslog -t --conmon-pidfile /run/user/1000/vfs-containers/b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0/userdata/conmon.pid --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /home/james/.local/share/containers/storage --exit-command-arg --runroot --exit-command-arg /run/user/1000 --exit-command-arg --log-level --exit-command-arg debug --exit-command-arg --cgroup-manager --exit-command-arg cgroupfs --exit-command-arg --tmpdir --exit-command-arg /run/user/1000/libpod/tmp --exit-command-arg --runtime --exit-command-arg /usr/local/bin/kata-runtime --exit-command-arg --storage-driver --exit-command-arg vfs --exit-command-arg --events-backend --exit-command-arg journald --exit-command-arg container --exit-command-arg cleanup --exit-command-arg --rm --exit-command-arg b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0]"
WARN[0004] Failed to add conmon to cgroupfs sandbox cgroup: error creating cgroup for cpu: mkdir /sys/fs/cgroup/cpu/libpod_parent: permission denied
DEBU[0004] Received: -1
DEBU[0005] Cleaning up container b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0
DEBU[0005] Tearing down network namespace at /run/user/1000/netns/cni-c0684446-1bfc-afb0-ad34-ea10dd16f93e for container b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0
DEBU[0005] unmounted container "b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0"
DEBU[0005] Cleaning up container b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0
DEBU[0005] Network is already cleaned up, skipping...
DEBU[0005] Container b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0 storage is already unmounted, skipping...
DEBU[0005] Container b9a23d5668025039d1dde04972f2f3fec39e6df1206954cd7c29243e819af0b0 storage is already unmounted, skipping...
DEBU[0005] ExitCode msg: "network device mode not determined correctly. mount sysfs in caller: oci runtime error"
ERRO[0005] Network device mode not determined correctly. Mount sysfs in caller: OCI runtime error I was hoping to make this document executable but since (currently) this can only work (I think) on a very limited range of distro versions, I'm not sure that's viable at this stage:
|
@jodh-intel Can you send me your kernel config? |
@amshinde - I'm using vanilla F30. Sent you the kernel config. |
@jodh-intel: How did you get rid of the network issue? I am hitting the same on CoreOS . Works with
|
@jodh-intel what is the status of this doc? currently we have a podman CI running with kata...more improvements should be done to this doc? thanks |
Adding myself and @c3d here. In any case, would be good some last review on this one considering the current scenarios (it's almost a note to self). |
Hi @fidencio - I'm currently updating this PR. It's probably going to be split into distro-specific instructions so that it fits the current |
Closing as we have now released 2.0. We'd like to interoperate with podman for 2.x but cannot until that project supports the shimv2 architecture. |
Add a doc explaining how to run Kata Containers rootless using podman.
This replaces PR #553.