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
