[kata-dev] Kata on Fedora experiment (modular kernel)

Jose Carlos Venegas Munoz jose.carlos.venegas.munoz at intel.com
Fri Jun 29 18:28:55 UTC 2018


Hi Stefan,

Thanks for sharing your experiments. Your approach to integrate Kata shows some
points improve to support this use case.

I did not consider in the past use the host kernel as the kata kernel but
definitely is a use case we could support.

A couple of questions related on how to mange the kernel and image when you
add Fedora RPMs.

Are you going to add a symlink to allow the kata runtime always find the latest
installed kata kernel ?

How are you planning to update the modules if a kernel changes ? The image will
by generated after a new kernel update? Or every time the kernel changes you
are going to update the kernel from package?

On Fri, Jun 29, 2018 at 06:42:27PM +0100, Stefan Hajnoczi wrote:
> Hi,
> I wanted to share some thoughts after running Kata on Fedora.  I built
> Kata from source and used the Fedora rootfs together with a vanilla
> modular kernel.  This configuration is similar to what I imagine
> official Fedora RPMs would eventually use, because they probably want to
> use a stock Fedora kernel instead of building a special monolithic
> kernel for Kata.
> 
> The Fedora rootfs was built like this:
> 
>   # KERNEL_MODULES_DIR=/lib/modules/$(uname -r) OS_VERSION=28 ./rootfs.sh fedora
> 
> My understanding is Kata wants *either* an initramfs or a disk image.
> Modular kernels typically need to load drivers before they can access
> the disk, so I opted for the initramfs even though it is several hundred
> megabytes.  The initramfs could probably be shrunk significantly with
> some work on the Fedora rootfs script.
> 
> This configuration required several tweaks to get Kata running.  I'm not
> going to create a patch series or send a pull request, because at this
> stage these are dirty hacks that cannot be merged.  But it's likely that
> other people will encounter these issues, so I'm including them below.
> 
> Stefan
> 
> ---
> 
>  * kata-agent assumes initramfs is equivalent to running the agent as
>    init.  In our case kata-agent *is* in an initramfs but *not* init, so
>    it calculates the wrong value for noPivotRoot:
> 
> diff --git a/agent.go b/agent.go
> index ec01250..182c2de 100644
> --- a/agent.go
> +++ b/agent.go
> @@ -830,7 +832,7 @@ func realMain() {
>                 running:    false,
>                 // pivot_root won't work for init, see
>                 // Documention/filesystem/ramfs-rootfs-initramfs.txt
> -               noPivotRoot:    os.Getpid() == 1,
> +               noPivotRoot:    true, // TODO check initramfs, not pid=1!  kata-agent might have been started by systemd form an initramfs os.Getpid() == 1,
>                 subreaper:      r,
>                 pciDeviceMap:   make(map[string]string),
>                 deviceWatchers: make(map[string](chan string)),
> 
>  * kata-agent assumes AF_VSOCK should be used if the guest kernel has
>    vsock support.  A generic kernel like the Fedora kernel will have
>    AF_VSOCK but that doesn't mean the virtio-serial device should be
>    ignored.  Perhaps change the check to see if
>    /dev/virtio-ports/agent.channel.0 is present?
> 
> diff --git a/channel.go b/channel.go
> index b4f8977..34ef292 100644
> --- a/channel.go
> +++ b/channel.go
> @@ -29,25 +29,29 @@ type channel interface {
>  }
>  
>  func newChannel() (channel, error) {
> +       // This is broken, it ignores the virtio-serial agent.channel.0 device
> +       // in favor of AF_VSOCK support, even on systems that are not going to
> +       // use AF_VSOCK but happen to have the drivers installed.
> +
>         // Check for vsock support.
> -       vSockSupported, err := isAFVSockSupported()
> -       if err != nil {
> -               return nil, err
> -       }
> -
> -       if vSockSupported {
> -               // Check if vsock socket exists. We want to cover the case
> -               // where the guest OS can support vsock, but the runtime is
> -               // still using virtio serial connection.
> -               exist, err := vSockPathExist()
> -               if err != nil {
> -                       return nil, err
> -               }
> -
> -               if exist {
> -                       return &vSockChannel{}, nil
> -               }
> -       }
> +//     vSockSupported, err := isAFVSockSupported()
> +//     if err != nil {
> +//             return nil, err
> +//     }
> +//
> +//     if vSockSupported {
> +//             // Check if vsock socket exists. We want to cover the case
> +//             // where the guest OS can support vsock, but the runtime is
> +//             // still using virtio serial connection.
> +//             exist, err := vSockPathExist()
> +//             if err != nil {
> +//                     return nil, err
> +//             }
> +//
> +//             if exist {
> +//                     return &vSockChannel{}, nil
> +//             }
> +//     }
>  
>         return &serialChannel{}, nil
>  }
> 
>  * The Fedora initramfs and modular kernel rely on udev to load the
>    virtio_console.ko driver.  Make sure to start kata-agent *after* the
>    agent device appears.  Note this change will break AF_VSOCK if you
>    choose to use that instead of virtio-serial!
> 
> diff --git a/kata-agent.service.in b/kata-agent.service.in
> index 861757d..5395047 100644
> --- a/kata-agent.service.in
> +++ b/kata-agent.service.in
> @@ -2,6 +2,8 @@
>  Description=Kata Containers Agent
>  Documentation=https://github.com/kata-containers/agent
>  Wants=kata-containers.target
> +BindsTo=dev-virtio\x2dports-agent.channel.0.device
> +After=dev-virtio\x2dports-agent.channel.0.device
>  
>  [Service]
>  # Send agent output to tty to allow capture debug logs
> 
>  * Make sure the rootfs has modprobe and udev.  Needed by the modular
>    kernel.
> 
> diff --git a/rootfs-builder/fedora/config.sh b/rootfs-builder/fedora/config.sh
> index a0ca15a..19fbc7b 100644
> --- a/rootfs-builder/fedora/config.sh
> +++ b/rootfs-builder/fedora/config.sh
> @@ -14,4 +14,4 @@ PACKAGES="iptables"
>  #Optional packages:
>  # systemd: An init system that will start kata-agent if kata-agent
>  #          itself is not configured as init process.
> -[ "$AGENT_INIT" == "no" ] && PACKAGES+=" systemd" || true
> +[ "$AGENT_INIT" == "no" ] && PACKAGES+=" systemd systemd-udev" || true



> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev




More information about the kata-dev mailing list