In os-autoinst we take a running VM snapshot by migrating the VM RAM/CPU to file and creating image overlays for each storage device. Then when the machine needs to be reverted, we can delete/recreate the image overlays, restart QEMU and perform a migration from file, which restores the running virtual machine.
QEMU also has a 'snapshot' feature, but it uses some of the same code as migration in addition to some features which are not well supported. So it makes sense to implement snapshots using the migration API which is very well supported.
Often reverting to a snapshot taken just after boot is faster than booting. If the RAM usage is low after boot, but systemd takes some time waiting for services to start, then it is a lot faster. This could reduce the time it takes to revert to only a few seconds.
In os-autoinst we take a running VM snapshot by migrating the VM RAM/CPU to file and creating image overlays for each storage device. Then when the machine needs to be reverted, we can delete/recreate the image overlays, restart QEMU and perform a migration from file, which restores the running virtual machine.
QEMU also has a 'snapshot' feature, but it uses some of the same code as migration in addition to some features which are not well supported. So it makes sense to implement snapshots using the migration API which is very well supported.
Often reverting to a snapshot taken just after boot is faster than booting. If the RAM usage is low after boot, but systemd takes some time waiting for services to start, then it is a lot faster. This could reduce the time it takes to revert to only a few seconds.
Code reference: https://github.com/os-autoinst/os-autoinst/blob/master/backend/qemu.pm#L280 https://github.com/os-autoinst/os-autoinst/blob/master/backend/qemu.pm#L417
FYI @shunghsiyu