Open Stack

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. 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? Thanks for the 
explanation! I agree it can solve the single host management daemon issue.

Cheers,
Tao

-- 
Into something rich and strange.