On Mon, Jul 06, 2020 at 18:15:55 +0200, Kevin Wolf wrote: > Am 03.07.2020 um 18:02 hat Daniel P. Berrangé geschrieben: > > On Fri, Jul 03, 2020 at 04:49:33PM +0100, Dr. David Alan Gilbert wrote: > > > * Daniel P. Berrangé (berra...@redhat.com) wrote: > > > > On Thu, Jul 02, 2020 at 01:12:52PM -0500, Eric Blake wrote: > > > > > On 7/2/20 12:57 PM, Daniel P. Berrangé wrote:
[...] > > migration only does vmstate, not disks. The current blockdev commands > > are all related to external snapshots, nothing for internal snapshots > > AFAIK. So we still need commands to load/save internal snapshots of > > the disk data in the qcow2 files. > > > > So we could look at loadvm/savevm conceptually as a syntax sugar above > > a migration transport that targets disk images, and blockdev QMP command > > that can do internal snapshots. Neither of these exist though and feel > > like a significantly larger amount of work than using existing functionality > > that is currently working. > > There is blockdev-snapshot-internal-sync, which does a disk-only > snapshot of a single node. A snapshot of multiple nodes can be taken by > putting multiple blockdev-snapshot-internal-sync inside a 'transaction' > command. Libvirt never implemented support for disk-only internal snapshots as I didn't think they are worth it. We also made a mistake by using the VIR_DOMAIN_SNAPSHOT_DISK_ONLY to switch to an external snapshot, so while the XML can modify the snapshot to be internal it's not very clear nor user-friendly to force an internal disk only snapshot. > If we want to build on top of this, we'd have to implement a > transactionable command for storing only the VM state to a specific > node. This would probably still be a long-running job. IMO we really want this also for external snapshots. Driving the migration as standard migration is really suboptimal especially when the user wants minimal downtime. Transactioning a post-copy style copy-on write migration would simplify this a lot. I agree though that this is for a different conversation.