[CRIU] implementing some kind of --leave-frozen option for c/r in CRIU

Tycho Andersen tycho.andersen at canonical.com
Mon May 16 15:39:43 PDT 2016


On Mon, May 16, 2016 at 03:34:59PM -0700, Andrew Vagin wrote:
> On Tue, May 10, 2016 at 11:04:56AM -0600, Tycho Andersen wrote:
> > Hi guys,
> > 
> > I'm looking at implementing some kind of --leave-frozen option in
> > CRIU, so that we can have a basic UX in LXD where we can wait for the
> > restore to be successful before we kill the checkpointed container. I
> > know p.haul does this by just using a callback, but it would be sort
> > of painful to absorb just the callback part without doing a lot of
> > extra engineering. We'll get LXD using p.haul someday, though :)
> > 
> > The actual --leave-frozen patch is not so bad (see attached), but I'm
> > not sure what to do about the network locking/unlocking bits.
> > 
> > It seems like it is always safe to do the bits in
> > cpt_unlock_tcp_connections() since that's just disabling tcp repair
> > mode, but all of the iptables rules seem necessary in order to keep
> > the network locked.
> > 
> > So my question is: is there a nice way we can "tag" these rules so
> > that something can come by and delete them later? I was thinking about
> > having criu add a comment (via -m comment --comment "CRIU-LOCK-RULE")
> > to each rule it adds, but I'm not sure if there's a better way, or if
> > I've missed something entirely.
> > 
> > Thanks!
> 
> We create a separate CRIU table, when we dump/restore a network
> namespace. Maybe we need to do the same for a case when we don't dump
> netns and collect all rules in this table.
> 
> In this case, we need only drop this table to unlock network.

I see that we create the separate table for local connections, but for
tcp connections they still go in the "filter" chain right?

static const char *nf_conn_cmd = "%s -t filter %s %s --protocol tcp "
        "--source %s --sport %d --destination %s --dport %d -j DROP";

Tycho


More information about the CRIU mailing list