先把基本理念搞清楚吧
- https://qemu-project.gitlab.io/qemu/interop/bitmaps.html
忽然意识到,overlayfs 可以实现 snapshot
https://qemu-project.gitlab.io/qemu/interop/live-block-operations.html
- live snapshot 和 live snapshot merge 是什么意思哇
https://wiki.qemu.org/Features/LiveBlockMigration
block.c
static SaveVMHandlers savevm_block_handlers = {
.save_setup = block_save_setup,
.save_live_iterate = block_save_iterate,
.save_live_complete_precopy = block_save_complete,
.save_live_pending = block_save_pending,
.load_state = block_load,
.save_cleanup = block_migration_cleanup,
.is_active = block_is_active,
};
block_loadblk_pwrite:似乎这就是写入 block 设备的位置,但是好奇怪啊
block_save_pending
所有的 hook
block_save_pending: 调用位置migration_iteration_run=>qemu_savevm_state_pendingget_remaining_dirty- 对于
BlkMigState::bmds_list中的所有的成员遍历,调用bdrv_get_dirty_count,从而统计 bitmap 的数量。
- 对于
下面两个的区别是什么:
block_save_iterate: 调用路径qemu_savevm_state_iterate核心路径上blk_mig_save_dirty_blockmig_save_device_dirty: 参数是 async 的blk_mig_save_dirty_block:异步的blk_pread+blk_send
block_save_complete: 用于完成 precopyblk_mig_save_dirty_block:参数是 sync 的
block-dirty-bitmap.c
AliasMapInnerNode都是想要表达什么?
我现在的感觉是,dirty bitmap 和 block 并不是互相替代的技术,就是存在 dirty bitmap 的信息需要被发送出去的。 如果去进一步的看 block/dirty-bitmap.c ,应该是可以验证这个想法的。
- dirty bitmap 中的保存的是谁的
关键结构体:
- DBMSaveState 持有多个 SaveBitmapState,后者一个负责一个 bitmap 的迁移。
-
BdrvDirtyBitmap
dirty_bitmap_save_setupinit_dirty_bitmap_migration:TODO 这里依赖的 block driver 的驱动让人感觉到非常迷茫blk_nextbdrv_filter_bsbdrv_next_all_statesadd_bitmaps_to_list- 利用
FOR_EACH_DIRTY_BITMAP逐个初始化SaveBitmapState,并且将其挂在到 DBMSaveState 上。
- 利用
send_bitmap_start:对于每一个函数
dirty_bitmap_save_iteratebulk_phasebulk_phase_send_chunk
接受端的:
dirty_bitmap_loaddirty_bitmap_load_startbdrv_create_dirty_bitmap: 创建 bitmap
dirty_bitmap_load_completedirty_bitmap_load_bitsbdrv_dirty_bitmap_deserialize_part: 将 bitmap 接受过来
测试一下吧
不太相信这种连存储也会迁移的操作,测试一下吧
那么这个 migration/block-dirty-bitmap.c 功能都是注入到哪些 level 的
本来以为是 qcow2 中做这个事情,实际上
本站所有文章转发 CSDN 将按侵权追究法律责任,其它情况随意。