Folks I've opened an issue in the govmm repository. Please speak up if you consider we shouldn't move govmm into kata-containers. Thanks -- Julio [1]: https://github.com/kata-containers/govmm/issues/195 On Fri, 2021-07-30 at 17:33 +0200, Christophe de Dinechin wrote: On 29 Jul 2021, at 06:11, David Gibson <david@gibson.dropbear.id.au<mailto:david@gibson.dropbear.id.au>> wrote: On Wed, Jul 28, 2021 at 10:09:21AM +0200, Fabiano Fidêncio wrote: On Wed, Jul 28, 2021 at 10:00 AM Peng Tao <bergwolf@hyper.sh<mailto:bergwolf@hyper.sh>> wrote: On 2021/7/28 15:50, Fabiano Fidêncio wrote: Folks, David Gibson, in an internal conversation, raised Today the pain of trying to fix a QEMU + kata-containers issue, having to update govmm, get it reviewed & merged on the govmm side, and only then be able to proceed with the work on QEMU + kata-containers. I can relate to that, I'm pretty sure other developers can relate to that as well. Considering that govmm is only used by kata-containers, wouldn't it be the case to have it as part of the virt-containers package rather than it's own project that we vendor? This was raised before. The reason we still used a separate repo for govmm was for kata 1.x back then. Now that kata 1.x is officially EOL, I'd say we should just move govmm into virtcontainers. Yay! I tend to see this as taking a step towards how we integrate cloud-hypervisor with kata-containers. Could you explain a bit on how it relates to cloud-hypervisor? Right now govmm only supports qemu. Do you plan to make it a generic vmm handling layer as it should be by its name? (Which I would love to see for sure!) What I meant was, nowadays the cloud-hypervisor code we deal with is under https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir..., firecracker also has its integration code as part of https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir.... With that in mind, govmm could actually be something like https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir... (which doesn't exist yet). Of course I'd like to have an abstraction that could actually handle all the VMMs, but at this point I'm not sure whether it's possible, or even worth it. That kind of depends what you're meaning. Making a *general-purpose* abstraction layer for VMMs is an extremely difficult problem, and not something we can reasonably tackle. That's essentially what libvirt aimed to be - it's been going for decades and it's at best kinda sorta there. Hard, but fair. +1 Making a VMM abstraction layer aimed solely at Kata's needs is much more manageable. In fact, we have one already: the 'hypervisor' interface in virtcontainers. IMO, there's not really a feasible abstraction boundary in between the hypervisor interface and the vmm itself. I think that's a significant why govmm has ended up as qemu-only and Kata-only in practice. But that's something to be calmly evaluated and discussed, as future steps. Did I answer your question, Tao? Best Regards, -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au<http://gibson.dropbear.id.au/> | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list <mailto:kata-dev@lists.katacontainers.io> kata-dev@lists.katacontainers.io <http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev