[CRIU] rewriting images via criu (or crit?)

Cyrill Gorcunov gorcunov at gmail.com
Tue Oct 21 01:56:24 PDT 2014


On Mon, Oct 20, 2014 at 07:22:53PM -0500, Tycho Andersen wrote:
> Hi all,
> 
> One of the problems we talked about at Plumbers was how to re-write cgroups. For
> example, if you migrate a container from a node with 4 cores (and thus a
> cpuset.cpus of 0-3), to a node with two cores (cpuset = 0-1), a write of 0-3
> into the new host's cpuset.cpus will fail, and the restore will fail.
> 
> Thus, we need some way to re-write these things (and images in general) so that
> we can handle this case and others. One option is to have a small syntax to
> rewrite things, and add support to the new crit tool either in C or in python
> depending on speed concerns to rewrite the images. Stealing some inspiration
> from xpath, below is my proposal for a language that does this rewriting.
> 
> In our example above, we want to write cpuset.cpus everywhere from 0-3 to 0-1:
> 
> cgroup_entry.controllers["cpuset" in cnames]//properties[name="cpuset.cpus"] set value=0-1
> 
> That is, first, match the buffer message type "cgroup_entry" with any
> controllers who have "cpuset" in them (the 'in' here would only work for
> 'repeated' message types), "//" says "recursively match any object with...",
> properties[name="cpuset.cpus"] says match any object in properties where the
> name is "0-3". Finally, set (get, delete) says what to do, and value says 'set
> the value member of each matching object to "0-3"'.
> 
> To do something a bit simpler, like setting a tasks exit code, you could do:
> 
> core_entry.tc set exit_code=1
> 
> That is, match all core entries' (there is only one in each image) tc object
> without constraints, and set the exit_code value to 1.
> 
> Some images have binary data in them, which we can just ignore for now.
> 
> The motivation for having a language (vs. just exposing the .proto definitions
> and allowing users to use the images directly) is that we don't want to force
> users to link against libprotobuf.
> 
> Does this sound reasonable? Anyone have any ideas on how to do this in a more
> succinct (but still flexible :) fashion?

As to me -- external tool for such modifications is better choise and it seems
crit is exactly fits here. This might have slight impact on the speed in compare
if the language would builtin into criu itself, but criu is already complex enough
so adding language engine here would simply overload I think.


More information about the CRIU mailing list