On Thu, 2 Apr 2020 at 11:11, Whaley, Graham <graham.whaley@intel.com> wrote:
OOI Ilya, is there a particular reason you are using Kata for this, and not using just vanilla VMs? I think adding Kata to the mix is going to make your life significantly harder - it is/was not designed to 'just work' on any kernel without specific features etc., as you are finding. If there is a specific reason to use Kata, fine, great - but we'd probably be interested to hear it 😉 If not, then your life might get significantly easier if you switch to using plain QEMU (and if your apps are in containers, then having docker installed on the client you run under vanilla QEMU etc.).
Graham, as I mentioned on IRC, I am pretty certain of what I'm after here. Conceptually, this is about running Kubernetes-in-Kubernetes, which is a know general patter, and this is just a variation of that. I have a requirement on having kernel isolation as well as a strong desire to test different kernels also. I actually have some of this working already. I do think it's plausible to consider not using kata and e.g. have qemu or firecracker inside container image and just run it from the pod, as I don't see a major need for storage after VM startup, it could be quite simple, yet I would still need to make networking work resource management would have to be take care of - whatever pod needs to run the VMM and whatever the VM resources should be set to... I guess for some use-cases this might just work, but ultimately one will eventually desire a more native pod-as-VM setup, something very much like kata. KubeVirt could be another option, but from what I gathered it's much less native to Kubenernetes, and you cannot map a KubeVirt VM to a service like you can with Kata.