Closed wrouesnel closed 8 years ago
multiple "runv exec" or multiple "runv start"(shared namespace) will have to share the same VM, so the process manage the VM will be the server to serve for all the "runv exec/start".
In old code, we wrote a simple server to do it, and later we converted it to runv containerd. (so runv containerd has two mode, one mode acts as docker-containerd. int other mode, it manges only one VM and serves to all of its "runv exec/start")
In future, we may remove the server, and use file-lock-based management, but we still need a server for the containers/processes' stdio before we use vsocks.
Thank you for the explanation. I also seem to have resolved my network namespace issue and it's working great now, so closing this as resolved!
I'm trying to get a feel for what the parameter
--solo-namespaced
actually implements when runningrunv containerd
.My impression from the code is that it shares events between containers started in separate VMs? But what is the benefit of doing this.
The context of the question is I'm trying to figure out if its possible at the moment for containers to share network namespace sensibly when runv is used with docker as a containerd backend. I don't get any errors, but it also doesn't seem to work.