[kata-dev] update on kata in fedora, and some questions
eric.ernst at intel.com
eric.ernst at intel.com
Wed Sep 11 20:30:57 UTC 2019
Just catching up on this thread, wanted to throw in some info...
On Wed, Sep 11, 2019 at 04:18:22PM -0400, Cole Robinson wrote:
> On 9/11/19 6:33 AM, Stefan Hajnoczi wrote:
> > On Sat, Sep 07, 2019 at 09:10:45PM -0400, Cole Robinson wrote:
> > Thanks for sharing your progress!
> >> * agent-0001-*.patch: Make kata-agent.service run after
> >> systemd-udev-settle.service. At one point in my experimenting I needed
> >> this: kata would communicate with the agent, but networking in the guest
> >> didn't seem to be set up yet, and configuring eth0 was failing. However
> >> if I revert this now it doesn't seem to cause any failures. This may be
> >> due to /etc/modules-load.d/kata-modules.conf loading the necessary bits
> >> early enough, but that may still be race-y. I figured I'd mention it for
> >> posterity.
> > I hit the same issue when using a Fedora modular kernel, I think.
> > kata-runtime is unhappy if kata-agent cannot respond with network
> > configuration details.
> >> * AGENT_INIT=no is the default, meaning /sbin/init == systemd, not
> >> /sbin/init == kata-agent. Is that generally the preferred config? When I
> >> was flailing around trying to get anything to work I tried
> >> AGENT_INIT=yes but didn't get anywhere
> > Could be monolithic (common with Kata) vs modular kernel issue. Have
> > all drivers loaded before kata-agent runs?
> I didn't have any working config with the stock Fedora kernel when I was
> trying AGENT_INIT=yes, driver loading was probably the root issue. I did
> get a dracut config working, but it doesn't look like
> BUILD_METHOD=dracut and AGENT_INIT=yes play well together, rootfs.sh
> dracut overlay setup is hardcoded for systemd at the moment.
> For the initial Fedora support I only plan to target systemd init,
> AGENT_INIT=yes can be something additive to explore on top of that
> initial base
If I was going to make a default for end users, I would consider running
the agent as init. This helps in removing systemd (footprint, attack
surface), and slight bootime improvement. Having agent as the init
process also makes sure that if things go sideways resource/scheduling
wise in the guest, the agent is the last to go (helpful for visibility).
Having said all this, sounds like there'll be some challenges in
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
More information about the kata-dev