Difference between revisions of "Images"

From CRIU
Jump to: navigation, search
(+netdev)
(Reformatted text to be more structured)
Line 1: Line 1:
 
The criu utility dumps the state of processes/containers into a set of image files. This article describes the format of them.
 
The criu utility dumps the state of processes/containers into a set of image files. This article describes the format of them.
  
== General format description ==
+
== Types of image files ==
 +
 
 +
CRIU images can be in one of formats
 +
 
 +
* crtools specific images in google protocol buffer format (PB format)
 +
* crtools specific images with binary data in it
 +
* image files in 3rd party format
 +
 
 +
== crtools-specific format description ==
  
Most of the crtools image files begin with 32-bit magic cookie followed by zero or more entries of the same type (not size!). Most of the entries are encoded in the Google Protocol Buffers format and each is preceded with 32-bit entry size value (not including this 32-bit value itself). Optionally each entry may be followed by extra payload which depends on the entry type.
+
All crtools-specific image files begin with 32-bit magic cookie. Images in PB format are followed by zero or more entries of the same type (not size!), each entry is preceded with 32-bit entry size value (not including this 32-bit value itself). Optionally each entry may be followed by extra payload which depends on the entry type.
  
IOW image files look like
+
IOW protocol-buffers image files look like
  
 
<pre>
 
<pre>
Line 19: Line 27:
 
The amount of entries in a image file depends on the type of file.
 
The amount of entries in a image file depends on the type of file.
  
== Types of image files ==
+
== Types of image files with PB data  ==
  
Images encoded with ProtocolBuffers can be one of
+
Such images can be one of
  
 
; Array image files
 
; Array image files
Line 104: Line 112:
 
  |}
 
  |}
  
There are, however, images which are not in ProtocolBuffers.
+
== Images with binary crtools data ==
 +
 
 +
These are
  
 
; Memory dumps
 
; Memory dumps

Revision as of 10:43, 6 December 2012

The criu utility dumps the state of processes/containers into a set of image files. This article describes the format of them.

Types of image files

CRIU images can be in one of formats

  • crtools specific images in google protocol buffer format (PB format)
  • crtools specific images with binary data in it
  • image files in 3rd party format

crtools-specific format description

All crtools-specific image files begin with 32-bit magic cookie. Images in PB format are followed by zero or more entries of the same type (not size!), each entry is preceded with 32-bit entry size value (not including this 32-bit value itself). Optionally each entry may be followed by extra payload which depends on the entry type.

IOW protocol-buffers image files look like

IMAGE_FILE ::= MAGIC { ENTRY }
ENTRY      ::= SIZE PAYLOAD [ EXTRA ]
PAYLOAD    ::= "message encoded in ProtocolBuffer format"
EXTRA      ::= "arbitrary blob, depends on the PAYLOAD contents"

MAGIC      ::= "32 bit integer"
SIZE       ::= "32 bit integer, equals the PAYLOAD length"

The amount of entries in a image file depends on the type of file.

Types of image files with PB data

Such images can be one of

Array image files
In these files the amount of entries can be any. You should read the image file up to the EOF to find out the exact number.
Single-entry image files
In these files exactly one entry is stored.

A file type can be guessed by the magic. The description of the entries in ProtocolBuffers language are in <type>.proto files.

name type description extra payload
inventory single-entry Top level description of images -
fdinfo array Open file descriptors -
regfile array Paths to files opened with open(2) syscall -
eventfd array Eventfd file information -
eventpoll array Eventpoll file information -
eventpoll-tfd array Target file descriptors of eventpoll fds -
inotify-file array Inotify file information -
inotify-wd array Watch descriptors of inotify fds -
signalfd array signalfd info
core single-entry Arch-dependent information (registers, etc.) -
mm single-entry Address space generic information (segments, exe file, etc.) -
vmas array Virtual mappings (mmap(2)) -
pipes array Pipes information -
pipes-data array Contents of pipes entry.bytes bytes of data sitting in a pipe
fifo array FIFO information -
fifo-data array Contents of FIFOs same as in pipes-data
pstree array Process tree linkage and IDs -
sigacts array Signal handling map -
unixsk array Unix domain sockets -
inetsk array PF_INET sockets, both IPv4 and IPv6 -
sk-queues array Contents of socket queues entry.length bytes of data, one entry per packet
itimers array Interval timers state -
creds single-entry Task credentials: uids, gids, caps, etc. -
fs single-entry Chroot and chdir information -
path-remap array File paths remaps -
ghost-file single-entry Ghost files (those, not visible from FS, but still used by tasks) Right after the entry up to the EOF goes the contents of the file
tcp-stream single-entry TCP connection state (including data in queues) -
mountpoints array Mountpoints information -
utsns single-entry Uname nodename and domainname of a UTS namespace -
tty array Information about opened tty-s
tty-info array Termios and similar stuff about tty-s
packetsk array Info about PF_PACKET sockets
netdev array Info about network devices

Images with binary crtools data

These are

Memory dumps
These files contain memory dumps. The format is
IMAGE ::= MAGIC [ ADDRESS DATA ]
ADDRESS ::= "64-bit virtual address"
DATA ::= "4K bytes blob (i.e. -- memory page)"