[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delv
From: |
Kevin Wolf |
Subject: |
Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delvm to QMP |
Date: |
Fri, 28 Aug 2020 10:46:27 +0200 |
Am 28.08.2020 um 08:20 hat Markus Armbruster geschrieben:
> Kevin Wolf <kwolf@redhat.com> writes:
>
> > Am 27.08.2020 um 13:06 hat Markus Armbruster geschrieben:
> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >>
> >> > On Wed, Aug 26, 2020 at 07:28:24PM +0100, Daniel P. Berrangé wrote:
> >> >> On Wed, Aug 26, 2020 at 05:52:06PM +0200, Markus Armbruster wrote:
> >> >> > Open questions:
> >> >> >
> >> >> > * Do we want the QMP command to delete existing snapshots with
> >> >> > conflicting tag / ID, like HMP savevm does? Or do we want it to
> >> >> > fail
> >> >> > the transaction?
> >> >>
> >> >> The intent is for the QMP commands to operate exclusively on
> >> >> 'tags', and never consider "ID".
> >> >
> >> > I forgot that even HMP ignores "ID" now and works exclusively in terms
> >> > of tags since:
> >> >
> >> >
> >> > commit 6ca080453ea403959ccde661030ca16264acc181
> >> > Author: Daniel Henrique Barboza <danielhb413@gmail.com>
> >> > Date: Wed Nov 7 11:09:58 2018 -0200
> >> >
> >> > block/snapshot.c: eliminate use of ID input in snapshot operations
> >>
> >> Almost a year after I sent the memo I quoted. It's an incompatible
> >> change, but nobody complained, and I'm glad we got this issue out of the
> >> way.
> >
> > FWIW, I would have ignored any complaint about incompatible changes in
> > HMP. It's not supposed to be a stable API, but UI.
>
> The iffy part is actually the loss of ability to access snapshots that
> lack a name. Complaints about that would have been valid, I think.
> Fortunately, there have been none.
'loadvm ""' should do the trick for these. The same way as you have to
use with 'savevm' to create them in non-prehistoric versions of QEMU.
We stopped creating snapshots with empty names by default in 0.14, so
they are probably not very relevant any more. (Versioned machine types
go back "only" to 1.0, so good luck loading a snapshot from an older
version. And I wouldn't bet money either on a 1.0 snapshot still working
with that machine type...)
Kevin
- Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delvm to QMP, Daniel P . Berrangé, 2020/08/21
- Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delvm to QMP, Markus Armbruster, 2020/08/26
- Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delvm to QMP, Daniel P . Berrangé, 2020/08/26
- Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delvm to QMP, Daniel P . Berrangé, 2020/08/26
- Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delvm to QMP, Markus Armbruster, 2020/08/27
- Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delvm to QMP, Kevin Wolf, 2020/08/27
- Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delvm to QMP, Markus Armbruster, 2020/08/28
- Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delvm to QMP,
Kevin Wolf <=
- Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delvm to QMP, Markus Armbruster, 2020/08/31
- Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delvm to QMP, Markus Armbruster, 2020/08/27
- Re: [PATCH v2 (BROKEN) 0/6] migration: bring improved savevm/loadvm/delvm to QMP, Daniel P . Berrangé, 2020/08/27