Open Stack

On 2019/12/5 17:31, Stefano Garzarella wrote:
> 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.
> 
Sorry, I don't quit understand your solution. Could you elaborate a bit 
more?

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?

Thanks,
Tao

-- 
Into something rich and strange.