| kata-irc-bot | <basma.elgaabouri> is it still possible to use 9p to share rootfs between the host and the vm in kata v2.x ? | 09:01 |
|---|---|---|
| kata-irc-bot | <jakob.naucke> That should still work, yes, just need to change `shared_fs` I think the option is called in the `configuration.toml`. | 09:03 |
| kata-irc-bot | <basma.elgaabouri> thanks | 09:45 |
| kata-irc-bot | <samuel.ortiz> @basma.elgaabouri We strongly advise using virtiofs instead of 9pfs though. | 09:53 |
| kata-irc-bot | <basma.elgaabouri> Hi, Is there a way to test the communication between the runtime and the agent? v2.x, with just running kata-runtime and kata-agent binaries? thank you | 10:37 |
| kata-irc-bot | <jakob.naucke> Do you just want to avoid running a container, but still run the Kata sandbox, or run runtime and agent on the same host without launching a VM? I think neither is currently possible without modifications. | 10:40 |
| kata-irc-bot | <basma.elgaabouri> Hi @jakob.naucke, where can i change the location where to find the container rootfs? | 10:42 |
| kata-irc-bot | <basma.elgaabouri> I was thinking of running the runtime and agent on the same host without launching a vm. what would those modifications be? | 10:44 |
| kata-irc-bot | <jakob.naucke> for container ID `foo`: `/run/kata-containers/shared/sandboxes/foo/shared/foo/rootfs` | 10:46 |
| kata-irc-bot | <jakob.naucke> I reckon they wouldn't be trivial. Off the top of my head (but there's very likely more): • Runtime ◦ Remove logic that launches VM ◦ Bend vsock logic to use normal Unix sockets • Agent ◦ Expect runtime communication on said Unix socket ◦ Expect rootfs on directory rather than virtio-fs mount ◦ Remove logic to handle devices But so much of the code assumes the host-guest setup it's likely not wo | 10:50 |
| kata-irc-bot | effort. What do you want to test here? | 10:50 |
| kata-irc-bot | <basma.elgaabouri> thank you, I'm trying to support a new hypervisor. | 10:59 |
| kata-irc-bot | <jakob.naucke> no easy feat :) maybe loop in @jose.carlos.venegas.m @anastassios.nanos @chen.bo here | 11:01 |
| kata-irc-bot | <anastassios.nanos> yeap, I agree with Jakob -- I would assume an easy prototype could be starting from an existing backend (virtcontainers/XX.go) and removing the logic that creates the sandbox -- then do the vsock->unix sock and finally run the agent to test communication. The next step would be to add the transport layer of your hypervisor to the agent/runtime ends, run the agent on your hypervisor and finally add the storage/container | 11:10 |
| kata-irc-bot | rootfs stuff | 11:10 |
| kata-irc-bot | <chen.bo> @basma.elgaabouri This is the PR that added the initial support of Cloud Hypervisor to Kata (1.x) back to the end of 2019: https://github.com/kata-containers/runtime/pull/2164 | 17:17 |
| kata-irc-bot | <chen.bo> To my understanding, the major work will be the implementation of the `hypervisor` interface [1] for the new hypervisor you would like to support, like what is done for Cloud Hypervisor [2]. [1] https://github.com/kata-containers/kata-containers/blob/main/src/runtime/virtcontainers/hypervisor.go#L848 [2] https://github.com/kata-containers/kata-containers/blob/main/src/runtime/virtcontainers/clh.go | 17:21 |
| kata-irc-bot | <chen.bo> Hope it helps. Of course, feel free to open an issue and describe your thoughts/questions. In that way, the broader community will able to help and share inputs. | 17:22 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!