Because CRIU allows to live migrate containers (see [[live migration]] for details), it might happen that CPU a container has been ran on differs from the target CPU. For most software this is usually not a problem, but if a program is compiled with optimizations involving a particular CPU feature (say, AVX instruction), the lack of the feature on a destination machine will lead to execution exception in a best case scenario.

−

Because CRIU allows to live migrate containers (see [[Live_migration | Live migration]] for details) it might happen that CPU a container has been ran on differ from the target CPU. For typical programs this might be not a problem but if a program get compiled with optimization which use a particular CPU feature (say AVX instruction and etc) the lack of the feature on a destination machine will lead to execution exception in a best case.

+

Therefore there should be a way to test if destination machine is capable of running container to be migrated. This is the purpose of <code>cpuinfo</code> command.

−

−

Thus there should be a way to test if destination machine is capable of running container being migrated.

== Saving CPU capabilities into an image file ==

== Saving CPU capabilities into an image file ==

−

CRIU does not write CPU capabilities into an image by default in a sake of speed. Instead one have to run CRIU as

+

CRIU does not write CPU capabilities into an image by default (for the sake of speed). Instead, one have to run CRIU as:

criu cpuinfo dump

criu cpuinfo dump

−

to produce ''cpuinfo'' image file which consists of the running CPU information and bits representing the supported capabilities.

+

The command creates a ''cpuinfo'' image file, containing information about the current CPU and some bits representing the supported capabilities.

== Testing CPU capabilities ==

== Testing CPU capabilities ==

−

To check if the capabilities saved in ''cpuinfo'' image file is match to the current CPU one should run

+

To check if the capabilities saved in ''cpuinfo'' image file are matching those of the current CPU, one should run:

criu cpuinfo check

criu cpuinfo check

Line 21:

Line 19:

== Checkpoint/Restore with CPU capabilities ==

== Checkpoint/Restore with CPU capabilities ==

−

While by default CRIU does not save CPU capabilities in image file one can pass '''--cpu-cap''' option to force CRIU to save and check CPU capabilities on dump and restore accordingly.

+

While by default CRIU does not save CPU capabilities in image file, one can pass <code>--cpu-cap</code> option to force CRIU to save and check CPU capabilities on dump and restore accordingly.

+

+

[[Category:API]]

Latest revision as of 08:17, 9 January 2018

Because CRIU allows to live migrate containers (see live migration for details), it might happen that CPU a container has been ran on differs from the target CPU. For most software this is usually not a problem, but if a program is compiled with optimizations involving a particular CPU feature (say, AVX instruction), the lack of the feature on a destination machine will lead to execution exception in a best case scenario.

Therefore there should be a way to test if destination machine is capable of running container to be migrated. This is the purpose of cpuinfo command.