I rebased the code with a recent of the code.
I applied the feedback for kern_snapshot.c: I updated the copyright and I remove the unnecessary headers.
I tested again to make sure that the suspend/restore functionalities are working (I applied the same test plan).

I renamed the limiting functions for the file descriptor as @emaste suggested.

Add EPRINTLN to handle raw mode when printing the error messages for the created functions.

In D34547#791959, @rew wrote:

What about receiving the file descriptors from the nvlist?

The sender (e.g., bhyvectl) opens the file descriptors and adds them to the nvlist; then bhyve gets the descriptors from the nvlist and writes to it. I think that would let us to skip out on adding the -t flag and ckp_path altogether..?

Part of the problem with that is, three file descriptors would need to be sent across. And considering the snapshot data model isn't set in stone..

it'd be nice if the snapshot feature only used one file descriptor to do its work.

thoughts?

I applied most of the changes recommended by @markj. I did not add the documentation for the "-t" yet. @gusev.vitaliy_gmail.com i did add VM_SNAPSHOT_REQ to vm_get_ioctls() and I did move init_checkpoint_thread() before cap_enter() in bhyverun.c; I did not implement the first recommendation yet considering the feedback from @markj and I don't know exactly if I should remove or not the "-t <checkpoint_dir_path>" approach. What do you think of this current patch version?

I did one more update to the proposed implementation. Initially I did a split in order to make the review process easier. After applying the recommended changes parts 2 and 3 of the stack are not needed anymore because the code turned out to be enough for one ticket. This last update contains all the changes for the capsicum integration and I will archive parts 2 and 3. If you have any others changes that you consider that should be applied please use only this ticket. I am eager to see what is your opinion after all the changes were applied.

I updated the revision to match the changes applied in https://reviews.freebsd.org/D34587 as well to solve an issue when the first disk path is /dev/md0. Now the snapshot directory can be specified at boot time using -t option.
I also applied the code refactorization to match part 3(https://reviews.freebsd.org/D34587) of the stack review.

In D34547#786979, @markj wrote:

In D34547#784041, @ionut.mihalache1506_gmail.com wrote:

The solution that I am working will add a way to specify the checkpoint directory at boot time.

To be clear, we should wait for further updates to the revision?

Made the necessary changes to the solution in order to solve a issue mentioned by @rew(there is a problem when the first disk uses /dev/md0. Instead of using the parent directory of the first disk, now the snapshot directory can be specified at boot time using -t option.
I also did refactor the code to remove unnecessary/unused parts before and after the changes.

In D34547#783705, @rew wrote:

You have broken up https://reviews.freebsd.org/D30471 into multiple reviews without addressing the issues I raised in the original review.

Fix year type in kern_snapshot.c.

I replaced ucl_parser_add_file with ucl_parser_add_fd in order to provide all the restrictions for the metadata file used during the restore process. I also a part of the changes suggested by emaste.

Rebased with a newer upstream and applied the changes from the review https://reviews.freebsd.org/D29538.

Removed redundant lines; applied most of the recommended changes.

vm_snapshot_kern_structs was called two times and probably caused a problem with save restore for multiple devices