[libvirt] [PATCH 1 of 4] [LXC] Detect support for NETNS in lxc driver initialization

Daniel Lezcano dlezcano at fr.ibm.com
Wed Jun 25 15:11:14 UTC 2008


Dan Smith wrote:
> DL> The CLONE_NEWNET will fail if the network namespace is not
> DL> compiled in. I understand this check but it looks like a little
> DL> random. You are not 100% sure this clone has failed because the
> DL> network namespace is not supported. That can be another subsystem
> DL> or namespace which has failed during the initialization of the
> DL> namespaces.
> 
> The check is performed twice, once with the basic set of flags and
> again with CLONE_NEWNET.  If the first check fails, we assume no LXC
> support (as we did before).  If the second fails, we assume LXC but no
> NETNS.  Is there something else I'm missing here?
> 
> DL> Why don't you simply check the presence of the 'netns' process ?
> 
> That seems like a valid way as well, although we already do our
> feature checks by testing the clone.  Also, by doing it this way, we
> have a better confirmation that an actual clone(CLONE_NEWNET) will
> work, IMHO.

You are not doing clone(CLONE_NEWNET) in this code.
You call 
clone(CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWUSER|CLONE_NEWIPC|SIGCHLD|CLONE_NEWNET)

When this call fails, you 'assume' netns is not compiled in.

I agree the clone should have returned ENOSYS in this case, but it 
returns EINVAL and that do not means 'netns in not active'.

If you look at the processes, you have a kthread called '[netns]', which 
indicates the network namespaces are actives in the kernel and this is 
not an assumption.

> DL> Concerning iproute2, I think this is the work of the installer to
> DL> check the dependencies, eg. the libvirt rpm depends on
> DL> iproute2-x.y.z version rpm.
> 
> Agreed, and I'm sure it will.  Note DV's second comment here:
> 
>   https://www.redhat.com/archives/libvir-list/2008-June/msg00232.html

In your code, you launch the ip command and if it fails with a 
particular exit code, you 'assume' netns is not supported. Another 
assumption ... IMHO you should rely on the package dependencies/command 
version. Or if you absolutely want to detect that at startup, perhaps 
doing "ip link help | grep netns" is more secure :)






More information about the libvir-list mailing list