Am 07.07.2020 um 08:38 hat Peter Krempa geschrieben: > 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.
This is an interesting point actually. And while the implementation of the post-copy style live snapshotting is for a different conversation, I think the implications it has on the API are relevant for us now. But even if we have an all-in-one snapshot job instead of a transaction to group all the individual operations together, I think you could still represent that by just specifying an empty list of nodes to be snapshotted. (I feel this is another argument for passing the nodes to include rather than nodes to exclude from the disk snapshot.) Kevin
