| kata-irc-bot | <jacobwgillespie> Ah, that might be it actually, I don't think the guest VM has mounted the debugfs (looks like systemd would have done that on a typical base image). I assume this means that I need to modify the rootfs to include the mount for `/sys/kernel/debug`? I'll look into that next, thanks! | 10:58 |
|---|---|---|
| kata-irc-bot | <jacobwgillespie> Follow question to the above, is it possible to mount arbitrary directories from the _guest_ VM into the container? For Tracee, I would typically need to `docker run -v /boot:/boot:ro` in order for it to read `/boot/config-*` . Using the equivalent `hostPath` volume and Firecracker, I believe Kata is (correctly) interpreting the intended mount as being from the host machine rather than the guest VM, and since that isn't | 11:03 |
| kata-irc-bot | supported on Firecracker, it's ignoring the mount. Is there an alternative way to instruct Kata to bind-mount a directory from the guest VM into the container? | 11:03 |
| kata-irc-bot | <dgibson> no there isn't | 11:23 |
| kata-irc-bot | <dgibson> there's not really any way to specify such a thing in the oci spec | 11:23 |
| kata-irc-bot | <dgibson> so any feature to allow that would necessarily be a hack | 11:23 |
| kata-irc-bot | <jacobwgillespie> Cool - yeah to put it another way, I want the container inside the VM's OCI spec to contain an unmodified mount. From what I can tell, rustjail is directly mounting mounts as defined in the OCI spec (https://github.com/kata-containers/kata-containers/blob/06f4ab10b4ce8b7fa61c3280b96953f57c6ee35a/src/agent/rustjail/src/mount.rs#L191), which I believe implies that Kata is rewriting that OCI spec before it reaches rustjail? It | 11:46 |
| kata-irc-bot | would be difficult to mark some mounts for rewriting and others to preserve in the OCI spec yes, I assume you'd need to mark those mounts as preserved via some mechanism (k8s annotations) and then pass the info through the OCI spec as custom annotations... My immediate workaround is to bake the contents of `/boot` in the guest VM inside the container image itself, which works since I control both the container image and the kernel, but I | 11:46 |
| kata-irc-bot | assume this will come up again (e.g., what if I want to bind mount a socket in the guest VM into two containers of a pod, etc) | 11:46 |
| kata-irc-bot | <dgibson> pretty much yes. now , the specs say that the runtime isn't supposed to change change behaviour based on annotations | 12:09 |
| kata-irc-bot | <dgibson> but kata already violates that in a bunch of ways, and can't really operate otherwise | 12:09 |
| kata-irc-bot | <dgibson> there's also a really nasty special hack in kata that if you -v /dev:/dev it will mount the guest's /dev into the container, rather than the host's | 12:10 |
| kata-irc-bot | <dgibson> or at least, there was in Kata1, not sure if that hack is still present in Kata2 | 12:10 |
| kata-irc-bot | <jacobwgillespie> It does look like that's still present, yes. Sanity question: if I add a `hostPath` volume and I'm using Firecracker, should I expect to see no mount and no files at that path at all in the running container since Firecracker is more limited? This is what I'm seeing, however there's some runtime code that implies that if filesystem sharing isn't supported, it would copy the intended files into the container FS, but that | 12:25 |
| kata-irc-bot | doesn't appear to be the case with my container, want to make sure I haven't misconfigured something | 12:25 |
| kata-irc-bot | <eric.ernst> Yeah, I understand the desired. As David highlighted - this isn’t supported in OCI, and we don’t have a pattern of exposing this via annotation or other today. | 15:50 |
| kata-irc-bot | <anastassios.nanos> that happens only if the hostPath refers to a file | 17:14 |
| kata-irc-bot | <anastassios.nanos> (the copy I mean) | 17:14 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!