[kata-dev] Having govmm as part of virtcontainers

Christophe de Dinechin cdupontd at redhat.com
Fri Jul 30 15:33:55 UTC 2021



> On 29 Jul 2021, at 06:11, David Gibson <david at 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 at 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/virtcontainers/pkg/cloud-hypervisor,
>> firecracker also has its integration code as part of
>> https://github.com/kata-containers/kata-containers/tree/main/src/runtime/virtcontainers/pkg/firecracker.
>> With that in mind, govmm could actually be something like
>> https://github.com/kata-containers/kata-containers/tree/main/src/runtime/virtcontainers/pkg/qemu
>> (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 <http://www.ozlabs.org/~dgibson>
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io <mailto:kata-dev at lists.katacontainers.io>
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev <http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20210730/e21625c4/attachment-0001.html>


More information about the kata-dev mailing list