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 :)
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
