Line 55: |
Line 55: |
| | crtools || Smart paths resolution || hard || - || Files can be overmounted. In this case CRIU will refuse the dump saying that file is not [[alive|invisible files]] but inaccessible by its name. Need a way to resolve paths to such. There are two ways: 1. Move mounts, that overlap the desired path temporarily, then open the file, then move the mountpoint back. 2. When creating a new mount pre-open an fd keeping the mountpoint. Later, do accurate path resolve and call openat() on proper mountpoint fd. | | | crtools || Smart paths resolution || hard || - || Files can be overmounted. In this case CRIU will refuse the dump saying that file is not [[alive|invisible files]] but inaccessible by its name. Need a way to resolve paths to such. There are two ways: 1. Move mounts, that overlap the desired path temporarily, then open the file, then move the mountpoint back. 2. When creating a new mount pre-open an fd keeping the mountpoint. Later, do accurate path resolve and call openat() on proper mountpoint fd. |
| |- | | |- |
− | | kernel/crtools || TCP repair fixes || hard || - || [[TCP repair TODO]] | + | | kernel/crtools || TCP repair fixes || hard || - || We can dump and restore live [[TCP connection]]. There are [[TCP repair TODO|some issues]] with it, that should be fixed. |
| |- | | |- |
− | | kernel?/crtools || TCP conntrack-ed connections || medium || - || Need to check whether connection tracking is ON, dump the needed conntrack info and put the tracker back. | + | | kernel?/crtools || TCP conntrack-ed connections || medium || - || When a container uses conntracks inside, we cannot just dump and restore alive TCP connection. Otherwise on restore the resurrected packets will be blocked by connection tracker as they would not be recognized as established connection. Need to check whether connection tracking is ON, dump the needed conntrack info and put the tracker back. |
| |- | | |- |
− | | crtools || Bridges in container || medium || - || | + | | crtools || Bridges in container || medium || - || The bridge device state should be read, saved and restored. |
| |- | | |- |
− | | crtools || VLANs in containers || medium || - || | + | | crtools || VLANs in containers || medium || - || Vlan (802.1q) device state should be read, saved and restored. |
| |- | | |- |
− | | crtools || PPP support || medium || - || | + | | crtools || [[PPP]] support || medium || - || PPP consists of several things, not just ppp devices. If container uses PPP we should take care of it, currently CRIU just aborts. |
| |- | | |- |
− | | crtools/kernel || NFS mount points support || hard || - || | + | | crtools/kernel || [[NFS mount points]] support || hard || - || NFS mount points from inside container cannot be easily restored. The thing is -- if we want to restore opened file we will go ahead and [[How hard is it to open a file|call]] the open system call. If the file in question resides on NFS, the latter might need to go to network to check whether the file actually exists and set up the handle. But if the networking is still not restored this operation would fail and we'll have to fail the whole restore. In order to untie this chicken-and-egg problem we may go in two directions. |
| |- | | |- |
− | | kernel || Seamless kernel upgrade || hard || xemul || | + | | kernel || [[Seamless kernel upgrade]] || hard || xemul || |
| |- | | |- |
| | crtools || Validate .img files || easy || - || [[CRIT]] For a given set of image files check, that they are in "restorable" shape | | | crtools || Validate .img files || easy || - || [[CRIT]] For a given set of image files check, that they are in "restorable" shape |