Checkpoint/Restore kata containers
[!WARNING] This doc is outdated. The Kata plugin is still WIP.
This doc describes the steps that have to be performed to save-migrate-resume a kata-container workload. It includes building a CRIU compatible kernel and rootfs, and a busy-box image which includes the cedana wrapper. These steps are also exactly what are performed by an end-to-end test for kata container workloads which are checkpointed and restored using cedana.
Get the fork of kata-containers, created under cedana. Switch to the rootfs-kernel branch.
Create the kernel compatible with CRIU : Steps documented here
Create a CRIU compatible rootfs and the corresponding image : Steps documented here
Create a custom busybox image with the cedana wrapper and the workload : Steps documented here
Copy the config file at the correct location
/opt/kata/share/defaults/kata-containers/
Run the workload:
Log into the VM:
Run the installation script inside the VM:
Create a checkpoint from the host: The “-d” flag corresponds to the path on the host where we want to save the checkpoint tar file. The file is saved as “dmp.tar”.
The mandatory argument is the VM name (test_vm) in our case. This command saves the tar file in the same folder as the cedana binary, as we have provided the argument as “.”
Run a new VM, with any dummy workload. Log into the VM and run the installation scripts. Now, we can restore the previous workload into the new VM. Again, the “-d” flag corresponds to the path on the host of the tar file.
The mandatory argument is the VM name of the VM into which we wish to perform the restore. In this case, it is “test_vm_2”, which is the new VM, running the dummy workload. Since the dmp.tar from the kata dump is present in the same directory as the cedana binary, we directly use “dmp.tar” as the path of the tar file.
Last updated
Was this helpful?