lxc-checkpoint: enable dirty memory tracking in criu #1299
Conversation
|
This pull request didn't trigger Jenkins as its author isn't in the whitelist. An organization member must perform one of the following:
Those commands are simple Github comments of the format: "jenkins: COMMAND" |
|
It seems my commit messages is formatted by github differently than expected (not at all). @tych0 This is my preparation for pre-dump support in lxd to easier test the code path. |
| /* Using --prev-images-dir works in older CRIU versions (2.3). | ||
| * For newer CRIU versions like 2.8 --track-mem needs to | ||
| * be added to the command-line. */ | ||
| DECLARE_ARG("--track-mem"); |
There was a problem hiding this comment.
Will the parser fail on older versions?
There was a problem hiding this comment.
Hmm, it seems the option is always needed. I just tried it with criu 2.3 which I thought worked without --track-mem. I will update the PR and remove the comment.
|
Other than the one comment, LGTM. We don't currently have any users of this code path, so if it's easier to just merge this as-is to experiment, that's fine with me. |
CRIU supports dirty memory tracking to take incremental checkpoints.
Incremental checkpoints are one way of reducing downtime during
migration. The first checkpoint dumps all the memory pages and the
second (and third, and fourth, ...) only dumps pages which have changed.
Most of the necessary code has already been implemented. This just adds
the existing functionality to lxc-checkpoint:
-p, --pre-dump Only pre-dump the memory of the container.
Container keeps on running and following
checkpoints will only dump the changes.
--predump-dir=DIR path to images from previous dump (relative to -D)
The following is an example from a container running CentOS 7 with psql
and tomcat:
# lxc-checkpoint -n c7 -D /tmp/cp -p
Container keeps on running
# du -h /tmp/cp
229M /tmp/cp
Sync initial checkpoint to destination
# rsync -a /tmp/cp host2:/tmp/
Sync file-system
# rsync -a /var/lib/lxc/c7 host2:/var/lib/lxc/
Final dump; container is stopped
# lxc-checkpoint -n c7 -D /tmp/cp --predump-dir=../cp -s
# du -h /tmp/cp2
90M /tmp/cp2
After transferring the second (incremental checkpoint) and the changes
to the container's file system the container can be restored on the
second host by pointing lxc-checkpoint to the second checkpoint
directory:
# lxc-checkpoint -n c7 -D /tmp/cp2 -r
Signed-off-by: Adrian Reber <areber@redhat.com>
|
New version pushed without the comment. --track-mem is now always enabled when --prev-images-dir is used. |
|
Ok, cool. +1 then, thanks! |
|
jenkins: test this please |
1 similar comment
|
jenkins: test this please |
CRIU supports dirty memory tracking to take incremental checkpoints.
Incremental checkpoints are one way of reducing downtime during
migration. The first checkpoint dumps all the memory pages and the
second (and third, and fourth, ...) only dumps pages which have changed.
Most of the necessary code has already been implemented. This just adds
the existing functionality to lxc-checkpoint:
-p, --pre-dump Only pre-dump the memory of the container.
Container keeps on running and following
checkpoints will only dump the changes.
--predump-dir=DIR path to images from previous dump (relative to -D)
The following is an example from a container running CentOS 7 with psql
and tomcat:
lxc-checkpoint -n c7 -D /tmp/cp -p
Container keeps on running
du -h /tmp/cp
229M /tmp/cp
Sync initial checkpoint to destination
rsync -a /tmp/cp host2:/tmp/
Sync file-system
rsync -a /var/lib/lxc/c7 host2:/var/lib/lxc/
Final dump; container is stopped
lxc-checkpoint -n c7 -D /tmp/cp --predump-dir=../cp -s
du -h /tmp/cp2
90M /tmp/cp2
After transferring the second (incremental checkpoint) and the changes
to the container's file system the container can be restored on the
second host by pointing lxc-checkpoint to the second checkpoint
directory:
lxc-checkpoint -n c7 -D /tmp/cp2 -r
Signed-off-by: Adrian Reber areber@redhat.com