On Fri, Jul 03, 2020 at 17:10:12 +0100, Dr. David Alan Gilbert wrote: > * Daniel P. Berrangé (berra...@redhat.com) wrote: > > 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:
[...] > > > Remind me, what was the problem with just making a block: migration > > > channel, and then we can migrate to it? > > > > 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. > > I think that's what we should aim for; adding this wrapper isn't gaining > that much without moving a bit towards that; so I would stick with the > x- for now. Relying on the HMP variants is IMO even worse. Error handling is terrible there. I'd vote even for a straight wrapper without any logic at this point. IMO it's just necessary to document that it's an intermediate solution which WILL be deprecated and removed as soon as a suitable replacement is in place. Not doing anything is the argument we hear for multiple years now and savevm/delvm/loadvm are now the only 3 commands used via the HMP wrapper in libvirt. Since deprecation is now a thing I think we can add a disposable inteface. In the end HMP will or will not need to remain anyways and the deprecation there is IMO less clear.