Open Stack

Hi Stefano,

On Wed, 2019-12-11 at 18:27 +0100, Stefano Garzarella wrote:
> Hi Sebastien,
> 
> On Thu, Dec 5, 2019 at 9:07 AM Boeuf, Sebastien <
> sebastien.boeuf at intel.com> wrote:
> > On Wed, 2019-12-04 at 17:36 +0000, Montes, Julio wrote:
> > 
> > Stefano,
> > 
> > 
> > > Do you think could be an easy change in the Kata runtime?
> > > I need to look better, but if you already know the answer you'll
> > > save me some time :)
> > 
> > ok, this means all kata components must be in the same network
> > namespace.
> > 
> > fortunately, kata-shim and qemu run in the same network namespace,
> > so the change should be easy, just move kata-proxy and kata-runtime 
> > into the same net namespace
> > 
> > 
> > Well in case of vsock, we don't need kata-proxy, the shim being
> > directly connected to the VM through vsock. And the kata-shim runs
> > in the same netns as the VMM, so we're good from this perspective.
> > 
> > In case of containerd-shimv2, we don't have kata-shim anymore, the
> > shim being a simple thread part of the kata-runtime process, which
> > means kata-runtime needs to enter the netns, and that's where it
> > might be pretty complex. IIRC, Julio did some experiments to run
> > the kata-runtime in a set of namespaces, but I don't think we
> > merged it, did we?
> 
> Looking in the code seems that kata-runtime uses the "vhostfd"
> parameter
> of the vsock device, this means that the vhost device (/dev/vhost-
> vsock)
> is opened by the runtime and then the file descriptor is passed to
> QEMU.
> This is great for this case because the netns assigned to the device
> is
> the one of the process that opened the /dev/vhost-vsock.
> 
> I tried containerd-shimv2 with the vhost-vsock modified to support
> netns
> and seems to work well.
> 
> Instead with v1 it doesn't work, maybe because kata-runtime and
> kata-shim run in two different netns. (or maybe I did something
> wrong,
> but it works disabling vsock or using the vhost-vsock without netns)
> 
> Does that make sense?

Yes I think your experiment and the result makes sense.

In case of v1, kata-shim runs in the same netns as QEMU, but kata-
runtime runs in a separate one (the default netns). Later when kata-
shim tries to access the fd, because it runs in a different netns than
kata-runtime, the permission is denied.

In case of v2, there's only one process, the containerd-shimv2, which
again runs on the default netns, but later will be the one trying to
connect to the vhost-vsock fd, which is why it will succeed. In this
case there's no more additional process connecting through vsock, it is
simply a different thread from containerd-shimv2.

At first, I didn't get the fact that the netns authorized to access
vsock had to be the one where the device was opened from. That's why my
analysis was completely reversed :)

Thanks,
Sebastien

> 
> Thanks,
> Stefano
> 
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.