Open Stack

On Thu, Dec 05, 2019 at 08:37:19PM +0800, Peng Tao wrote:
> On 2019/12/5 18:15, Stefano Garzarella wrote:
> > On Thu, Dec 05, 2019 at 05:49:08PM +0800, Peng Tao wrote:
> > > On 2019/12/5 17:31, Stefano Garzarella wrote:
> > > > On Thu, Dec 05, 2019 at 10:39:08AM +0800, Peng Tao wrote:
> > > > > 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.
> > > > 
> > > Sorry, I don't quit understand your solution. Could you elaborate a bit
> > > more?
> > 
> > Sure, sorry for that.
> > 
> > > 
> > > In my scenario, there is one management daemon on the host that needs to
> > > talk to many guests via vsock. Assuming the daemon lives in the host init
> > > netns, and each guest vmm is put in a different netns, how do you propose to
> > > solve the problem?
> > 
> > 1. If we add an ioctl to vhost-vsock, the VMM can specify the ID of netns
> >     where to assign the device (this requires to assign an id to the netns):
> > 
> >      $ ip netns add ns1
> >      $ ip netns add ns2
> >      $ ip netns set ns2 2
> > 
> >      # qemu runs in ns1 but vsock device is assigned to ns2 (e.g. the
> >      # management daemon is running in ns2)
> >      $ ip netns exec ns1 qemu-system-x86_64 ... \
> >          -device vhost-vsock-device,guest-cid=3,netns-id=2
> > 
> >      # qemu runs in ns1 but vsock device is assigned to init_ns (e.g. -1)
> >      $ ip netns exec ns1 qemu-system-x86_64 ... \
> >          -device vhost-vsock-device,guest-cid=3,netns-id=-1
> > 
> OK, I see. So this is more like what we have for the netdev, where the
> device itself can live in a different netns than the one vmm is in. Then we
> can put all the vsock devices and the host management daemon in the same
> netns so that they can talk, and each vmm can still live in a its own netns.

Right!

> Sounds good to me;)

:-)

> 
> > 2. If we extend the ip-link(8) we could do as for veth devices:
> > 
> >      $ ip link list (modified to show vsock${guest_cid}, so in this case
> >                      there are two guests with CID 42 and 54)
> >      ...
> >      10: vsock42: ...
> > 
> >      11: vsock54: ...
> > 
> >      # assign to ns2
> >      $ ip link set vsock42 netns ns2
> >      $ ip link set vsock54 netns ns2
> > 
> >      # assign to init_ns (netns accepts also pid, so we can use 1 for init_ns)
> >      $ ip link set vsock42 netns 1
> >      $ ip link set vsock54 netns 1
> > 
> > The second option could be more complicated to do.
> Yeah, it the same idea in a different form right?

Exactly!

> Thanks for the
> explanation! I agree it can solve the single host management daemon issue.

Thanks for your feedback!

Cheers,
Stefano