* Peter Krempa (pkre...@redhat.com) wrote: > 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.
Only if we come up with a list of what we actually need to do to properly fix it; I'm not suggesting we actually need to do the work, but we should figure out what we need to do. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK