Level 2 : savevm loadvm

使用方法

hmp 命令:

savevm

disk 的 snapshot :

https://wiki.qemu.org/Features/SnapshotsMultipleDevices
https://superuser.com/questions/1768173/how-to-work-with-qemu-snapshots-savevm-in-a-way-that-is-predictable-like-virtual

qemu savevm 基本原理

首先，vmstate 是一定会保存的，此外，savevm 的时候，机器立刻停止下来，将所有的内存全部都写入到盘中后，然后继续运行。

main
- qemu_default_main
  - qemu_main_loop
    - main_loop_wait
      - os_host_main_loop_wait
        
        glib_pollfds_poll
        
        g_main_context_dispatch
        
        g_main_context_dispatch_unlocked
        
        tcp_chr_read
        
        monitor_read
        
        readline_handle_byte
        
        monitor_command_cb,
        
        handle_hmp_command
        
        handle_hmp_command_exec,
        
        hmp_savevm
        
        save_snapshot,
        
        bdrv_all_create_snapshot,
        
        bdrv_all_get_snapshot_devices,

保存使用的盘的逻辑参考 bdrv_all_get_snapshot_devices()

HMP savevm 默认没有显式指定 vmstate 设备
QEMU 会在默认候选块设备列表里，从前往后找
选中第一个“可写、已插入、支持 internal snapshot”的块设备
在这台机器当前的候选顺序里，virtio-scsi_1 是第一个满足条件的设备

使用 qemu-img snapshot -l “$d” 来查询，结果如下，可见，这个 qcow2 中把 vmstate 完整的保留了:

./virtio-scsi_1
Snapshot list:
ID        TAG               VM SIZE                DATE     VM CLOCK     ICOUNT
1         vm-20260112055339 1.56 GiB 2026-01-12 18:53:39 00:06:37.803
2         a                1.45 GiB 2026-01-23 22:00:42 00:04:30.948
3         mark             1.14 GiB 2026-01-23 22:04:44 00:00:49.611
4         abc              1.15 GiB 2026-01-23 22:09:20 00:01:37.400
5         vm-20260407172427 4.49 GiB 2026-04-07 17:24:27 00:06:40.465

如果想显式控制保存到哪块盘

{
  "execute": "snapshot-save",
  "arguments": {
    "job-id": "snapsave0",
    "tag": "my-snap",
    "vmstate": "某个块节点名",
    "devices": ["盘1节点", "盘2节点"]
  }
}

这样可以稳定控制：

vmstate 到底写到哪个块节点
哪些磁盘参与这次内部快照

原来区别是在这里的?

migration_connect 中说明了:

    if (migrate_background_snapshot()) {
        qemu_thread_create(&s->thread, MIGRATION_THREAD_SNAPSHOT,
                bg_migration_thread, s, QEMU_THREAD_JOINABLE);
    } else {
        qemu_thread_create(&s->thread, MIGRATION_THREAD_SRC_MAIN,
                migration_thread, s, QEMU_THREAD_JOINABLE);
    }

我靠，真的没想到吧，:

tcp_chr_read
- monitor_read
  - readline_handle_byte
    - monitor_command_cb
      - handle_hmp_command
        
        handle_hmp_command_exec
        
        handle_hmp_command_exec
        
        hmp_savevm
        
        save_snapshot
        
        qemu_savevm_state
        
        qemu_savevm_state_iterate
        
        ram_save_iterate
        
        ram_find_and_save_block
        
        get_queued_page
        
        poll_fault_page
        
        migrate_background_snapshot

基本上可以看到 qemu 的 savevm 的流程基本上热迁移非常类似:

- qemu_savevm_state_iterate
   - ram_save_iterate
      - 92.66% ram_find_and_save_block
         - 72.24% ram_save_host_page (inlined)
            + 35.82% pss_find_next_dirty
            - 35.50% ram_save_target_page
               - 34.11% save_zero_page (inlined)
                  + 31.40% buffer_is_zero (inlined) (极其合理，在这里有一个很长的 page fault 触发流程)
                  + 1.43% ram_transferred_add
                    0.81% save_page_header (inlined)
               + 1.18% ram_save_page (inlined)
         - 20.03% find_dirty_block (inlined)
            - 19.85% pss_find_next_dirty (这里有我的调试语句，所以占比极高)

savevm 的时候，虚拟机会卡住。

看看 vhost 对于热迁移的优化

https://patchew.org/QEMU/20250813164856.950363-1-vsementsov@yandex-team.ru/

基本实验

🤒  qemu-img snapshot -l boot1
Snapshot list:
ID      TAG               VM_SIZE                DATE        VM_CLOCK     ICOUNT
1       vm-20260112055339      0 B 2026-01-12 05:53:39  0000:06:37.803         --

(qemu) info snapshots
There is no snapshot available.
(qemu) savevm
(qemu) info snapshots
List of snapshots present on all disks:
ID      TAG               VM_SIZE                DATE        VM_CLOCK     ICOUNT
--      vm-20260112055339 1.56 GiB 2026-01-12 05:53:39  0000:06:37.803         --
(qemu) loadvm vm-20260112055339

qemu-img snapshot -a vm-20260112055339 disk.qcow2

qemu-img convert
-f qcow2
-O qcow2
-s vm-20260112055339
disk.qcow2
disk-from-snapshot.qcow2

savevm/loadvm 也会有这个问题: 也会遇到这个问题

Error: State blocked by non-migratable device '0000:00:07.0/nvme'

这个是新问题哦

Error: Device 'pflash1' is writable but does not support snapshots

本站所有文章转发 CSDN 将按侵权追究法律责任，其它情况随意。