SH> But there is no guarantee that the checkpointer is in the netns
SH> which we would call the 'top level' netns.  Which means that, at
SH> restart, whether or not the devices which are in what we call the
SH> top level netns are in fact inherited or not, will depend on
SH> conditions of the checkpointer.  Do we care?  (I thought we did,
SH> but maybe we don't... it's unlikely to happen anyway)

Well, when we discussed this on IRC with Oren, I think we came to the
conclusion that since network namespaces aren't hierarchical, that we
would restore things from the "viewpoint" of the process that
checkpointed them.  It gives us a sane way to ensure that the peer
devices residing in the init netns can be put back there, even though we
don't checkpoint everything in the init netns (like eth0).

If you checkpoint a veth from within the container and you have a peer
device that is outside the container (but not in a netns that is
checkpointed as part of a task), it's going to fail and tell you that
one of your peers leaked to the outside.  I think that's sane and
preferred behavior, no?  If you're using macvlan and you checkpoint
from within the container, I think you should be okay, as long as
there is a appropriately named device to base the restored devices on
in whatever netns your restore process is in.

-- 
Dan Smith
IBM Linux Technology Center
email: danms@us.ibm.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html