Open Stack

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.

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	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20210729/0e6ac396/attachment.sig>