On 23.07.2020 20:39, Peter Xu wrote:
On Thu, Jul 23, 2020 at 11:03:55AM +0300, Denis Plotnikov wrote:
On 22.07.2020 19:30, Peter Xu wrote:
On Wed, Jul 22, 2020 at 06:47:44PM +0300, Denis Plotnikov wrote:
On 22.07.2020 18:42, Denis Plotnikov wrote:
On 22.07.2020 17:50, Peter Xu wrote:
Hi, Denis,
Hi, Peter
...
How to use:
1. enable background snapshot capability
virsh qemu-monitor-command vm --hmp migrate_set_capability
background-snapshot on
2. stop the vm
virsh qemu-monitor-command vm --hmp stop
3. Start the external migration to a file
virsh qemu-monitor-command cent78-bs --hmp migrate exec:'cat
./vm_state'
4. Wait for the migration finish and check that the migration
has completed state.
Thanks for continued working on this project! I have two high level
questions
before dig into the patches.
Firstly, is step 2 required? Can we use a single QMP command to
take snapshots
(which can still be a "migrate" command)?
With this series it is required, but steps 2 and 3 should be merged into
a single one.
I'm not sure whether you're talking about the disk snapshot operations, anyway
yeah it'll be definitely good if we merge them into one in the next version.
After thinking for a while, I remembered why I split these two steps.
The vm snapshot consists of two parts: disk(s) snapshot(s) and vmstate.
With migrate command we save the vmstate only. So, the steps to save
the whole vm snapshot is the following:
2. stop the vm
virsh qemu-monitor-command vm --hmp stop
2.1. Make a disk snapshot, something like
virsh qemu-monitor-command vm --hmp snapshot_blkdev drive-scsi0-0-0-0
./new_data
3. Start the external migration to a file
virsh qemu-monitor-command vm --hmp migrate exec:'cat ./vm_state'
In this example, vm snapshot consists of two files: vm_state and the disk file.
new_data will contain all new disk data written since [2.1.] executing.
But that's slightly different to the current interface of savevm and loadvm
which only requires a snapshot name, am I right?
Yes
Now we need both a snapshot
name (of the vmstate) and the name of the new snapshot image.
Yes
I'm not familiar with qemu image snapshots... my understanding is that current
snapshot (save_snapshot) used internal image snapshots, while in this proposal
you want the live snapshot to use extrenal snapshots.
Correct, I want to add ability to make a external live snapshot. (live =
asyn ram writing)
Is there any criteria on
making this decision/change?
Internal snapshot is supported by qcow2 and sheepdog (I never heard of
someone using the later).
Because of qcow2 internal snapshot design, it's quite complex to
implement "background" snapshot there.
More details here:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg705116.html
So, I decided to start with external snapshot to implement and approve
the memory access intercepting part firstly.
Once it's done for external snapshot we can start to approach the
internal snapshots.
Thanks,
Denis
