Re: [PATCH net-next 0/6] vsock: assign the guest vsock device to a network namespace

On Wed, Sep 16, 2026 at 02:36:07PM +0200, Stefano Garzarella wrote:

On Tue, Sep 15, 2026 at 10:43:23AM -0700, Bobby Eshleman wrote:

quoted

On Tue, Sep 15, 2026 at 12:16:47PM +0200, Stefano Garzarella wrote:

quoted

On Fri, Sep 04, 2026 at 10:30:28AM -0700, Bobby Eshleman wrote:

quoted

On Fri, Sep 04, 2026 at 10:55:17AM +0200, Stefano Garzarella wrote:

quoted

On Wed, Sep 02, 2026 at 04:00:46PM -0700, Bobby Eshleman wrote:

quoted

vsock network namespaces let a host put each VM in a namespace of its
own. A guest has no equivalent yet. It has a single G2H device that
cannot be assigned to a network namespace.

Thanks for this, I'll do a proper review next week, in the mean time some
comments below:

quoted

This series lets a guest move that device into a network namespace. A
new ioctl on /dev/vsock, IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS, assigns the
device to the namespace of the calling process. The namespace's existing

Why an ioctl?

I'm asking because I'd like to know if you've already considered any
alternatives (sysfs, netlink, etc.)

How do you think the ioctl should be used? Should we provide an userspace
tool, or extending some existing tools?

Thanks,
Stefano

Really only because /dev/vsock exists and the prior series used it.

Yeah, I vaguely remember that we may have discussed switching to netlink in
that thread, but I can't find it.

quoted

Considering netlink, it might be the better option because there is a
lot of prior art solving problems we might have in the future. For
example, I was thinking about when users suddenly lose access to vsock,
with just the current assign ioctl there is no way for apps or users to
figure out why this happened. We can have an ioctl() setter for user,
but in netdev world users can actually get a notification via netlink as
to which namespace the device went to and what its ifindex is there (see
__dev_change_net_namespace() for the RTM_DELLINK and RTM_NEWLINK
messages). There is probably more, but that's the case that comes to
mind.

netlink seems like the right way to go, do you think it'll be a real pain to
implement?

It is really not bad... it'll include a yaml spec in
Documentation/netlink/specs/ of call names and perms, a new target for
generated code in the Makefile, a handler, and then
tools/net/ynl/ynl-regen.sh generates the plumbing.

Ah, nice! So, do you want to try that direction?

Thanks,
Stefano

Let's give it a go. I have a draft of it for v2 and looks reasonable to
me.

Best,
Bobby