Open Stack

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 at gibson.dropbear.id.au<mailto: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<mailto: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
_______________________________________________
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


_______________________________________________

kata-dev mailing list

<mailto:kata-dev at lists.katacontainers.io>

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/20210803/55f2b395/attachment-0001.html>