
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>

</head>

<body dir="ltr">

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<font size="2"><span style="font-size:11pt">

<div>Hi Stefano<br>

</div>

<div><br>

</div>

<div>> Cool!<br>

> @Julio, let me know if you have a POC working. I can try with my<br>

> changes.</div>

<div><br>

</div>

<div>I only have a PoC for mntns, but I can help you with the netns, I'll <br>

</div>

<div>send you the patch once it's ready<br>

</div>

</span></font></div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<br>

</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

-</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

Julio<br>

</div>

<div id="appendonsend"></div>

<hr style="display:inline-block;width:98%" tabindex="-1">

<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Stefano Garzarella <sgarzare@redhat.com><br>

<b>Sent:</b> Monday, December 16, 2019 6:16 AM<br>

<b>To:</b> Boeuf, Sebastien <sebastien.boeuf@intel.com>; Montes, Julio <julio.montes@intel.com><br>

<b>Cc:</b> kata-dev@lists.katacontainers.io <kata-dev@lists.katacontainers.io><br>

<b>Subject:</b> Re: [kata-dev] vsock & network namespaces in Kata</font>

<div> </div>

</div>

<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">

<div class="PlainText">On Mon, Dec 16, 2019 at 07:30:40AM +0000, Boeuf, Sebastien wrote:<br>

> Hi Stefano,<br>

> <br>

> On Fri, 2019-12-13 at 09:35 +0100, Stefano Garzarella wrote:<br>

> > Hi Sebastien,<br>

> > <br>

> > On Thu, Dec 12, 2019 at 09:32:18PM +0000, Boeuf, Sebastien wrote:<br>

> > > On Wed, 2019-12-11 at 18:27 +0100, Stefano Garzarella wrote:<br>

> > > > On Thu, Dec 5, 2019 at 9:07 AM Boeuf, Sebastien <<br>

> > > > sebastien.boeuf@intel.com> wrote:<br>

> > > > > On Wed, 2019-12-04 at 17:36 +0000, Montes, Julio wrote:<br>

> > > > > > Do you think could be an easy change in the Kata runtime?<br>

> > > > > > I need to look better, but if you already know the answer<br>

> > > > > > you'll<br>

> > > > > > save me some time :)<br>

> > > > > <br>

> > > > > ok, this means all kata components must be in the same network<br>

> > > > > namespace.<br>

> > > > > <br>

> > > > > fortunately, kata-shim and qemu run in the same network<br>

> > > > > namespace,<br>

> > > > > so the change should be easy, just move kata-proxy and kata-<br>

> > > > > runtime <br>

> > > > > into the same net namespace<br>

> > > > > <br>

> > > > > <br>

> > > > > Well in case of vsock, we don't need kata-proxy, the shim being<br>

> > > > > directly connected to the VM through vsock. And the kata-shim<br>

> > > > > runs<br>

> > > > > in the same netns as the VMM, so we're good from this<br>

> > > > > perspective.<br>

> > > > > <br>

> > > > > In case of containerd-shimv2, we don't have kata-shim anymore,<br>

> > > > > the<br>

> > > > > shim being a simple thread part of the kata-runtime process,<br>

> > > > > which<br>

> > > > > means kata-runtime needs to enter the netns, and that's where<br>

> > > > > it<br>

> > > > > might be pretty complex. IIRC, Julio did some experiments to<br>

> > > > > run<br>

> > > > > the kata-runtime in a set of namespaces, but I don't think we<br>

> > > > > merged it, did we?<br>

> > > > <br>

> > > > Looking in the code seems that kata-runtime uses the "vhostfd"<br>

> > > > parameter<br>

> > > > of the vsock device, this means that the vhost device<br>

> > > > (/dev/vhost-<br>

> > > > vsock)<br>

> > > > is opened by the runtime and then the file descriptor is passed<br>

> > > > to<br>

> > > > QEMU.<br>

> > > > This is great for this case because the netns assigned to the<br>

> > > > device<br>

> > > > is<br>

> > > > the one of the process that opened the /dev/vhost-vsock.<br>

> > > > <br>

> > > > I tried containerd-shimv2 with the vhost-vsock modified to<br>

> > > > support<br>

> > > > netns<br>

> > > > and seems to work well.<br>

> > > > <br>

> > > > Instead with v1 it doesn't work, maybe because kata-runtime and<br>

> > > > kata-shim run in two different netns. (or maybe I did something<br>

> > > > wrong,<br>

> > > > but it works disabling vsock or using the vhost-vsock without<br>

> > > > netns)<br>

> > > > <br>

> > > > Does that make sense?<br>

> > > <br>

> > > Yes I think your experiment and the result makes sense.<br>

> > <br>

> > ;-)<br>

> > <br>

> > > In case of v1, kata-shim runs in the same netns as QEMU, but kata-<br>

> > > runtime runs in a separate one (the default netns). Later when<br>

> > > kata-<br>

> > > shim tries to access the fd, because it runs in a different netns<br>

> > > than<br>

> > > kata-runtime, the permission is denied.<br>

> > <br>

> > Do you think can easly changed?<br>

> > <br>

> > As Julio suggested, maybe we can move kata-runtime in the same netns.<br>

> <br>

> As I said earlier, this is something that could work, and I think Julio<br>

> had a POC on this. The point is to make sure we run the entire process<br>

> into the netns.<br>

<br>

Cool!<br>

@Julio, let me know if you have a POC working. I can try with my<br>

changes.<br>

<br>

> <br>

> A possible hack would be to enter the netns when we open /dev/vhost-<br>

> vsock, but that also means we need to enter the netns anytime the kata-<br>

> runtime tries to communicate with the agent. Not sure this is a viable<br>

> solution.<br>

<br>

Perhaps it might be enough to enter into the netns only during the open.<br>

If the fd is not closed, it remains associated with the netns, so there<br>

is no need to re-enter for communication.<br>

<br>

> <br>

> > <br>

> > Otherwise, is it possible to open the /dev/vhost-vsock in kata-<br>

> > runtime,<br>

> > then pass it to kata-shim that pass it to QEMU?<br>

> <br>

> From a pure technical standpoint, I'd say yes, but problem is, we would<br>

> modify the shim and the kata-runtime/kata-shim interaction quite a lot.<br>

> The kata-shim has been designed to be as simple as possible and act as<br>

> a thin wrapper between containerd/crio and the container running in the<br>

> VM.<br>

> <br>

<br>

Got it. If the hack above works, there's no point in complicating the<br>

architecture.<br>

<br>

> > <br>

> > So if we can solve this easily, it seems that there are no big issues<br>

> > for Kata with this new feature that I would like to introduce on<br>

> > Linux.<br>

> <br>

> I agree, I think that eventually if Kata wants this feature to be<br>

> supported, it will work out of the box for v2, and depending on the<br>

> need for v1, the changes might be introduced.<br>

> <br>

<br>

Great! Thank you very much for your collaboration,<br>

Stefano<br>

<br>

</div>

</span></font></div>

</body>

</html>