Images

Jump to navigation

Jump to search

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[edit]

CRIU images can be in one of the following formats

• criu specific images in google protocol buffer format (PB format)
• criu specific images with binary data in it
• image files in 3rd party format (a.k.a. raw images)

Images in criu-specific format[edit]

All criu-specific image files begin with 2 32-bit magic cookies. The first cookie is the type of file (see below) the second is the optional sub-type of image. 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.

Currently there are 3 types of images

• Inventory file

• This is the image file describing the set. It doesn't have sub-type magic.

• Image file

• Regular image. Most of the text below is about these files.

• Auxiliary file

• File that is not image, but criu generates one and it happens to be in protobuf format too. For now we have only stats and irmap cache files of that type. They also have sub-type magic.

IOW protocol-buffers image files look like

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

Or, you can visualize it like

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

Images with PB data[edit]

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 respective .proto files which reside in images/

directory in the source tree.

filesopened withopen(2)

syscallAddress spaceinformation (VMAs, segments, exe file, etc.)entry.bytes

bytes of data sitting in a pipetree linkageUnix socketsentry.length

bytes of data, one entry per packetinvisible files)invisible filesTCP connectionstate (including data in queues)entry.inq_len

bytes of in-queue data followed by entry.outq_len

bytes of out-queue dataMountpointsinformationTTYsTTYsnetworkdevices### Images with memory dumps[edit]

Main article: memory dumps.

Anonymous memory contents (both private and shared) is stored in two types of images:

• Pagemap files
• These files contain info about which virtual regions are populated with data. The file is a set of protobuf messages.

|

Note: Even though pagemap is an array kind of image (and can be included to the previous type), first pb message is of type pagemap_head and all the following ones are of type pagemap_entry.- Pages files

• These contain 4k pages that are to be put into the memory according to the pagemap.

Raw images[edit]

These images contain data collected by CRIU with the help of some external tools.

Notes about protobuf[edit]

We have a registered field number (1018) for custom options of all kinds. See protobuf/opts.proto for more info.

See also[edit]

CRIT: a tool to decode images to a human readable formatWhat's bad with V1 imagesImage field mergingMemory dumps