Changes

Jump to navigation Jump to search
631 bytes removed ,  15:34, 23 September 2015
no edit summary
Line 14: Line 14:  
|-
 
|-
 
| crtools || Non-full mntns dump || medium || - || Systemd launches services in a new mount namespace with a single change -- /tmp is re-mounted into a private one(PrivateTmp option). Need to invent an API for dumping only a part of mntns.
 
| crtools || Non-full mntns dump || medium || - || Systemd launches services in a new mount namespace with a single change -- /tmp is re-mounted into a private one(PrivateTmp option). Need to invent an API for dumping only a part of mntns.
|-
  −
| kernel/crtools || Remap [[Vdso]] || medium || - || When at restore VDSO is found not in the place it was on dump we should <code>mremap()</code> one. Unfortunately not always we can do it, need to fix the kernel.
   
|-
 
|-
 
| crtools || Make dump and restore work under [[selinux]] || medium || - || Selinux imposes more restrictions on the stuff we typically do.
 
| crtools || Make dump and restore work under [[selinux]] || medium || - || Selinux imposes more restrictions on the stuff we typically do.
Line 96: Line 94:  
|-
 
|-
 
| 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.
 
| 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 || - || The bridge device state should be read, saved and restored.
  −
|-
  −
| crtools || VLANs in containers || medium || - || Vlan (802.1q) device state should be read, saved and restored.
  −
|-
  −
| 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 || - || 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.
 
| 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.

Navigation menu