CRIU 0.2 and Linux Containers - new features
On Habré already published an article dedicated to the release of CRIU 0.1. This version of the product was not functional enough and rather demonstrated the performance of a unique technology developed by Parallels.
Since then, a lot of work has been done and the possibilities of the CRIU came very close to the main goal: the preservation and restoration of the Linux container. Despite the fact that so far only an empty container with a standard set of processes is supported, there is every reason to believe that the project is doomed to success.
And if you are not interested in containers, then you might like another new feature - support for saving and restoring pseudo-terminals, for which the screen session is well suited to illustrate. First you need to run several applications, such as top and vim, and disconnect from the session. After saving and restoring the screen-session and child processes using CRIU, you can reconnect to the screen-session and make sure that the running processes retain their state. For greater persuasiveness, between the moments of saving and restoring you can restart the computer or restore the screen session on another machine.
')
The link is a video clip that demonstrates how the CRIU saves and restores the state of the vncserver with a screensaver to which the client is connected:
This example is notable because during the saving and restoration of the server state, the connection to the client is also restored. That is, everything is transparent to the client (with the exception of a short service delay).
I decided to slightly dilute the articles on new versions of CRIU with interesting points from the project development process. Today I will talk about testing and the format of the dump files.
It is clear that for the success of the project can not do without quality testing. Therefore, we decided that automated testing should be implemented at the earliest stages of development. The groundwork was taken for testing the same functionality in the OpenVZ project. After completion of the project, we have created a comprehensive system for unit-testing. Each test is run separately and passes through 3 stages: preparation of the environment, “demonization” and waiting for a signal (which must be sent from the outside after saving and restoring the test), checking the result. Tests are conditionally divided for two groups. The first group is static tests that prepare a certain constant environment or state and “fall asleep” waiting for a signal. The second group is streaming tests that constantly change their state and / or environment (for example, data is sent via a TCP connection).
Today, the unit-testing system of CRIU includes about 70 individual test programs. In this case, the system allows you to run each of the tests both in the current and in the isolated namespace (that is, in fact, in the container).
The architectural aspects of the program must be carefully considered at the design stage, since then it will be very difficult to change something. The data retention format was one such architectural aspect for CRIU. It was necessary to solve two main tasks, namely:
We looked at all the most common and popular formats and settled on protobuf (Protocol Buffers), developed by Google, as it is supported by libraries for different programming languages and its format allows you to add new fields with backward compatibility.
Unfortunately, sometimes it is necessary not only to add new fields, but also to change the data structure. Therefore, dump files are versioned.
Parallels Company is actively developing the CRIU project and our next major goal is to learn how to save and restore the state of the OpenVZ container. This will eliminate the support for the migration of the OpenVZ container in the kernel, freeing up developer resources and thereby accelerating the development of the OpenVZ project.
habrahabr.ru/post/148413
ru.wikipedia.org/wiki/CRIU
lwn.net/Articles/517079
criu.org/LXC
Since then, a lot of work has been done and the possibilities of the CRIU came very close to the main goal: the preservation and restoration of the Linux container. Despite the fact that so far only an empty container with a standard set of processes is supported, there is every reason to believe that the project is doomed to success.
And if you are not interested in containers, then you might like another new feature - support for saving and restoring pseudo-terminals, for which the screen session is well suited to illustrate. First you need to run several applications, such as top and vim, and disconnect from the session. After saving and restoring the screen-session and child processes using CRIU, you can reconnect to the screen-session and make sure that the running processes retain their state. For greater persuasiveness, between the moments of saving and restoring you can restart the computer or restore the screen session on another machine.
')
The link is a video clip that demonstrates how the CRIU saves and restores the state of the vncserver with a screensaver to which the client is connected:
This example is notable because during the saving and restoration of the server state, the connection to the client is also restored. That is, everything is transparent to the client (with the exception of a short service delay).
Several features of CRIU development.
I decided to slightly dilute the articles on new versions of CRIU with interesting points from the project development process. Today I will talk about testing and the format of the dump files.
Unit tests
It is clear that for the success of the project can not do without quality testing. Therefore, we decided that automated testing should be implemented at the earliest stages of development. The groundwork was taken for testing the same functionality in the OpenVZ project. After completion of the project, we have created a comprehensive system for unit-testing. Each test is run separately and passes through 3 stages: preparation of the environment, “demonization” and waiting for a signal (which must be sent from the outside after saving and restoring the test), checking the result. Tests are conditionally divided for two groups. The first group is static tests that prepare a certain constant environment or state and “fall asleep” waiting for a signal. The second group is streaming tests that constantly change their state and / or environment (for example, data is sent via a TCP connection).
Today, the unit-testing system of CRIU includes about 70 individual test programs. In this case, the system allows you to run each of the tests both in the current and in the isolated namespace (that is, in fact, in the container).
Data file format
The architectural aspects of the program must be carefully considered at the design stage, since then it will be very difficult to change something. The data retention format was one such architectural aspect for CRIU. It was necessary to solve two main tasks, namely:
- The format must be extensible with the ability to maintain backward compatibility;
- The format should be common to allow easy access to data from other applications.
We looked at all the most common and popular formats and settled on protobuf (Protocol Buffers), developed by Google, as it is supported by libraries for different programming languages and its format allows you to add new fields with backward compatibility.
Unfortunately, sometimes it is necessary not only to add new fields, but also to change the data structure. Therefore, dump files are versioned.
Conclusion
Parallels Company is actively developing the CRIU project and our next major goal is to learn how to save and restore the state of the OpenVZ container. This will eliminate the support for the migration of the OpenVZ container in the kernel, freeing up developer resources and thereby accelerating the development of the OpenVZ project.
habrahabr.ru/post/148413
ru.wikipedia.org/wiki/CRIU
lwn.net/Articles/517079
criu.org/LXC
Source: https://habr.com/ru/post/152903/
All Articles