[kata-dev] vsock & network namespaces in Kata

Stefano Garzarella sgarzare at redhat.com
Thu Dec 5 09:31:01 UTC 2019


On Thu, Dec 05, 2019 at 10:39:08AM +0800, Peng Tao wrote:
> On 2019/12/5 01:05, Stefano Garzarella wrote:
> > On Wed, Dec 04, 2019 at 03:54:06PM +0000, Montes, Julio wrote:
> > > > - Host: assign the same CID of VMs running in different network
> > > >   namespaces
> > > 
> > > this means two VMs running in different namespace can use the same CID?
> > 
> > Exactly.
> > 
> > > currently we use VHOST_VSOCK_SET_GUEST_CID to get a unique context ID, is this going to change?
> > 
> > The only change is that the CID is unique in the network namespace
> > domain.
> > 
> > > 
> > > > 1. Is the VMM (e.g. QEMU) running in a network namespace?
> > > 
> > > yes, see https://github.com/kata-containers/runtime/blob/62cd08044d78912228d9dc800cb1b8bd3de3b971/virtcontainers/sandbox.go#L1024-L1041
> > > 
> > > > 2. Is the host application, that use vsock to communicate with the
> > > >    guest, running in the same network namespace?
> > > 
> > > afaik, no
> > 
> > This could be a problem with the RFC that I sent, because we allow only
> > the processes in the same netns of the VMM, to communicate with the
> > guest.
> > 
> > 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 :)
> Hi Stefano,

Hi Tao,

> 
> While I understand the motivation of the change, do users have an option to
> opt out of the namespaced vsock communication? I'm considering a possible
> scenario that someone uses a single host daemon to manage all the guests
> like we did in the hyperd project. Then there is no way for such a daemon to
> communicate with guests with namespaced vsock.
> 

It could be possible, but we would like to avoid it, because if the kernel
is compiled with netns support, then we would like to leave it also in vsock.

A possible solution whould be to provide a way to define the netns
assigned to the device, adding a new ioctl to vhost-vsock device (and a new
parameter to the QEMU's vsock device) or extending ip-link(8) to
handle vsock devices.

Do you think it'll be okay?

Thanks,
Stefano




More information about the kata-dev mailing list