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@xxxxxxxxxx _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
