Firecracker 如何用 snapshot-editor 将 diff 快照合并到基础 memory 文件【免费下载链接】firecrackerSecure and fast microVMs for serverless computing.项目地址: https://gitcode.com/GitHub_Trending/fi/firecracker当你先为一个 microVM 创建了 full 快照、随后又多次创建Diff快照时每个 diff 快照的 memory 文件通常不能直接用来恢复 microVM必须按创建顺序逐层合并回最初的 base memory 文件上。Firecracker 随发行版提供的snapshot-editor工具中的edit-memory rebase子命令完成这件事把 diff 文件中实际存在的数据块覆盖写入 base 文件执行完后 base 文件就变成了一个可恢复resume-able的快照 memory 文件。先弄清 base 与 layer 的对应关系Firecracker 的快照由两个文件组成来自 snapshot-editor 文档vmstate文件vCPU 状态、设备状态等 Firecracker 内部数据memory文件guest 内存内容。快照文档对合并对象有明确定义base第一次调用/snapshot/createAPI 生成的 memory 文件layer之后每次/snapshot/create调用生成的 memory 文件。两个直接影响操作路径的规则diff 快照的 memory 文件一般不可直接恢复必须与 base 合并成完整快照快照创建的先后顺序很重要合并时必须按创建顺序逐层进行。另外注意diff 快照功能目前处于 developer preview 状态旧工具rebase-snap已废弃见 DEPRECATED.md应使用snapshot-editor。准备生成 base 和 layer 文件合并操作本身只针对 memory 文件前提是你已经通过 Firecracker API 拿到了 full 和 diff 快照。按 snapshot-support.md 中的流程先暂停 microVMcurl --unix-socket /tmp/firecracker.socket -i \ -X PATCH http://localhost/vm \ -H Accept: application/json \ -H Content-Type: application/json \ -d { state: Paused }前提条件是 microVM 已处于 booted 状态。成功后 microVM 被保证处于Paused状态。创建 full 快照basecurl --unix-socket /tmp/firecracker.socket -i \ -X PUT http://localhost/snapshot/create \ -H Accept: application/json \ -H Content-Type: application/json \ -d { snapshot_type: Full, snapshot_path: ./snapshot_file, mem_file_path: ./mem_file }之后 microVM 运行一段时间产生内存写入后用同样的接口把snapshot_type改为Diff创建 diff 快照layercurl --unix-socket /tmp/firecracker.socket -i \ -X PUT http://localhost/snapshot/create \ -H Accept: application/json \ -H Content-Type: application/json \ -d { snapshot_type: Diff, snapshot_path: ./snapshot_file_2, mem_file_path: ./mem_file_2 }snapshot_type缺省为Full所以做 diff 时必须显式指定。两次调用分别产生的mem_file、mem_file_2就是下一步合并的 base 和 layer对应的snapshot_file、snapshot_file_2是各自的 vmstate 文件后面验证时要用。关于 diff 内容的两点边界如果配置/machine-config时启用了track_dirty_pagesdiff 快照只包含精确的脏页未启用时 Firecracker 用mincore(2)判断页面该方式仅在关闭 swap 时有效且可能包含比必要的更多的页文件仍是稀疏的。执行合并edit-memory rebaserebase子命令把diff快照的 memory 文件合并到 base memory 文件之上来自 snapshot-editor.mdsnapshot-editor edit-memory rebase \ --memory-path MEMORY_PATH \ --diff-path DIFF_PATHMEMORY_PATHbase memory 文件的路径DIFF_PATHdiff memory 文件的路径。文档给出的示例snapshot-editor edit-memory rebase \ --memory-path ./memory_file \ --diff-path ./diff_file结合上面的 API 示例实际执行就是snapshot-editor edit-memory rebase \ --memory-path ./mem_file \ --diff-path ./mem_file_2需要注意的操作事实该命令原地修改 base 文件——base 会“持续地被之前合并的 layer 信息更新”而 diff 文件只被读取。合并前 base 文件若还要保留原样请自行先复制一份有多个 layer 时对每个 layer 重复执行该命令顺序与创建顺序一致。每合并一层base 就前进一步直到合并到描述目标内存状态的那一层为止。从 edit_memory.rs 的实现可以看到rebase以只读方式打开 diff 文件、以写方式打开 base 文件按数据块把 diff 内容覆盖到 base 上打开文件失败、seek 失败或sendfile失败时会返回对应的错误如Could not open memory file、Failed to send the file命令以非零错误结束。验证加载合并后的快照并恢复快照文档给出的成功条件是执行 rebase 后base 文件就成为“描述 layer 创建时刻内存状态”的可恢复快照 memory 文件。实际的验证方式就是让一个新的 Firecracker 进程加载它。一个关键规则不要合并各次创建调用产生的 vmstate 文件。加载时应使用与“最后合并到 base 上的那个 memory 文件”同一次 API 调用所产生的 state 文件。以上面的例子先 full 的./snapshot_file后 diff 的./snapshot_file_2应使用./snapshot_file_2搭配合并后的./mem_file。在 microVM 配置完成之前发送/snapshot/load只允许在 boot 前调用此时只可先配置 logger 和 metricscurl --unix-socket /tmp/firecracker.socket -i \ -X PUT http://localhost/snapshot/load \ -H Accept: application/json \ -H Content-Type: application/json \ -d { snapshot_path: ./snapshot_file_2, mem_backend: { backend_path: ./mem_file, backend_type: File }, track_dirty_pages: true, resume_vm: false }加载成功后文档描述的 Effects 是完整 microVM 状态被载入当前 Firecracker 进程且 microVM 处于Paused状态需要再 resume 才能运行curl --unix-socket /tmp/firecracker.socket -i \ -X PATCH http://localhost/vm \ -H Accept: application/json \ -H Content-Type: application/json \ -d { state: Resumed }能成功 resume 即说明合并产物可用。如果 load 失败Firecracker 会报告具体错误并直接结束当前进程因为它可能处于无效状态此时应回到检查 state 文件与 memory 文件是否匹配、合并顺序是否正确。限制与注意事项diff 快照功能处于developer preview合并流程也在预览特性范围内使用恢复的前提条件同样适用加载方需要能访问与原 microVM 相同相对路径下的磁盘 backing 文件、TAP、vsock socket 等宿主资源通过Filebackend 加载后memory 文件必须被视为不可变——外部再修改它会导致 guest 内存损坏因此不要在 microVM 运行期间对它再执行rebase若还想从恢复出的 microVM 继续做 dirty page tracking 的 diff 快照需要在LoadSnapshot请求里再次显式设置track_dirty_pages该配置不会随快照保存旧工具rebase-snap已列入废弃清单新流程统一使用snapshot-editor edit-memory rebase。【免费下载链接】firecrackerSecure and fast microVMs for serverless computing.项目地址: https://gitcode.com/GitHub_Trending/fi/firecracker创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Firecracker 如何用 snapshot-editor 将 diff 快照合并到基础 memory 文件【免费下载链接】firecrackerSecure and fast microVMs for serverless computing.项目地址: https://gitcode.com/GitHub_Trending/fi/firecracker当你先为一个 microVM 创建了 full 快照、随后又多次创建Diff快照时每个 diff 快照的 memory 文件通常不能直接用来恢复 microVM必须按创建顺序逐层合并回最初的 base memory 文件上。Firecracker 随发行版提供的snapshot-editor工具中的edit-memory rebase子命令完成这件事把 diff 文件中实际存在的数据块覆盖写入 base 文件执行完后 base 文件就变成了一个可恢复resume-able的快照 memory 文件。先弄清 base 与 layer 的对应关系Firecracker 的快照由两个文件组成来自 snapshot-editor 文档vmstate文件vCPU 状态、设备状态等 Firecracker 内部数据memory文件guest 内存内容。快照文档对合并对象有明确定义base第一次调用/snapshot/createAPI 生成的 memory 文件layer之后每次/snapshot/create调用生成的 memory 文件。两个直接影响操作路径的规则diff 快照的 memory 文件一般不可直接恢复必须与 base 合并成完整快照快照创建的先后顺序很重要合并时必须按创建顺序逐层进行。另外注意diff 快照功能目前处于 developer preview 状态旧工具rebase-snap已废弃见 DEPRECATED.md应使用snapshot-editor。准备生成 base 和 layer 文件合并操作本身只针对 memory 文件前提是你已经通过 Firecracker API 拿到了 full 和 diff 快照。按 snapshot-support.md 中的流程先暂停 microVMcurl --unix-socket /tmp/firecracker.socket -i \ -X PATCH http://localhost/vm \ -H Accept: application/json \ -H Content-Type: application/json \ -d { state: Paused }前提条件是 microVM 已处于 booted 状态。成功后 microVM 被保证处于Paused状态。创建 full 快照basecurl --unix-socket /tmp/firecracker.socket -i \ -X PUT http://localhost/snapshot/create \ -H Accept: application/json \ -H Content-Type: application/json \ -d { snapshot_type: Full, snapshot_path: ./snapshot_file, mem_file_path: ./mem_file }之后 microVM 运行一段时间产生内存写入后用同样的接口把snapshot_type改为Diff创建 diff 快照layercurl --unix-socket /tmp/firecracker.socket -i \ -X PUT http://localhost/snapshot/create \ -H Accept: application/json \ -H Content-Type: application/json \ -d { snapshot_type: Diff, snapshot_path: ./snapshot_file_2, mem_file_path: ./mem_file_2 }snapshot_type缺省为Full所以做 diff 时必须显式指定。两次调用分别产生的mem_file、mem_file_2就是下一步合并的 base 和 layer对应的snapshot_file、snapshot_file_2是各自的 vmstate 文件后面验证时要用。关于 diff 内容的两点边界如果配置/machine-config时启用了track_dirty_pagesdiff 快照只包含精确的脏页未启用时 Firecracker 用mincore(2)判断页面该方式仅在关闭 swap 时有效且可能包含比必要的更多的页文件仍是稀疏的。执行合并edit-memory rebaserebase子命令把diff快照的 memory 文件合并到 base memory 文件之上来自 snapshot-editor.mdsnapshot-editor edit-memory rebase \ --memory-path MEMORY_PATH \ --diff-path DIFF_PATHMEMORY_PATHbase memory 文件的路径DIFF_PATHdiff memory 文件的路径。文档给出的示例snapshot-editor edit-memory rebase \ --memory-path ./memory_file \ --diff-path ./diff_file结合上面的 API 示例实际执行就是snapshot-editor edit-memory rebase \ --memory-path ./mem_file \ --diff-path ./mem_file_2需要注意的操作事实该命令原地修改 base 文件——base 会“持续地被之前合并的 layer 信息更新”而 diff 文件只被读取。合并前 base 文件若还要保留原样请自行先复制一份有多个 layer 时对每个 layer 重复执行该命令顺序与创建顺序一致。每合并一层base 就前进一步直到合并到描述目标内存状态的那一层为止。从 edit_memory.rs 的实现可以看到rebase以只读方式打开 diff 文件、以写方式打开 base 文件按数据块把 diff 内容覆盖到 base 上打开文件失败、seek 失败或sendfile失败时会返回对应的错误如Could not open memory file、Failed to send the file命令以非零错误结束。验证加载合并后的快照并恢复快照文档给出的成功条件是执行 rebase 后base 文件就成为“描述 layer 创建时刻内存状态”的可恢复快照 memory 文件。实际的验证方式就是让一个新的 Firecracker 进程加载它。一个关键规则不要合并各次创建调用产生的 vmstate 文件。加载时应使用与“最后合并到 base 上的那个 memory 文件”同一次 API 调用所产生的 state 文件。以上面的例子先 full 的./snapshot_file后 diff 的./snapshot_file_2应使用./snapshot_file_2搭配合并后的./mem_file。在 microVM 配置完成之前发送/snapshot/load只允许在 boot 前调用此时只可先配置 logger 和 metricscurl --unix-socket /tmp/firecracker.socket -i \ -X PUT http://localhost/snapshot/load \ -H Accept: application/json \ -H Content-Type: application/json \ -d { snapshot_path: ./snapshot_file_2, mem_backend: { backend_path: ./mem_file, backend_type: File }, track_dirty_pages: true, resume_vm: false }加载成功后文档描述的 Effects 是完整 microVM 状态被载入当前 Firecracker 进程且 microVM 处于Paused状态需要再 resume 才能运行curl --unix-socket /tmp/firecracker.socket -i \ -X PATCH http://localhost/vm \ -H Accept: application/json \ -H Content-Type: application/json \ -d { state: Resumed }能成功 resume 即说明合并产物可用。如果 load 失败Firecracker 会报告具体错误并直接结束当前进程因为它可能处于无效状态此时应回到检查 state 文件与 memory 文件是否匹配、合并顺序是否正确。限制与注意事项diff 快照功能处于developer preview合并流程也在预览特性范围内使用恢复的前提条件同样适用加载方需要能访问与原 microVM 相同相对路径下的磁盘 backing 文件、TAP、vsock socket 等宿主资源通过Filebackend 加载后memory 文件必须被视为不可变——外部再修改它会导致 guest 内存损坏因此不要在 microVM 运行期间对它再执行rebase若还想从恢复出的 microVM 继续做 dirty page tracking 的 diff 快照需要在LoadSnapshot请求里再次显式设置track_dirty_pages该配置不会随快照保存旧工具rebase-snap已列入废弃清单新流程统一使用snapshot-editor edit-memory rebase。【免费下载链接】firecrackerSecure and fast microVMs for serverless computing.项目地址: https://gitcode.com/GitHub_Trending/fi/firecracker创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
