Re: [PATCH v0 0/4] background snapshot

[Peter Xu]

On Fri, Jul 24, 2020 at 11:06:17AM +0300, Denis Plotnikov wrote:
> 
> 
> 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.

Fair enough.  Let's start with external snapshot then.  Thanks,

-- 
Peter Xu