On Tue, Apr 04, 2023 at 19:21:01 +0200, Pavel Hrdina wrote:
On Tue, Apr 04, 2023 at 03:03:56PM +0200, Peter Krempa wrote:
> On Mon, Mar 13, 2023 at 16:42:10 +0100, Pavel Hrdina wrote:
> > When reverting to external snapshot we need to create new overlay qcow2
> > files from the disk files the VM had when the snapshot was taken.
> >
> > There are some specifics and limitations when reverting to a snapshot:
> >
> > 1) When reverting to last snapshot we need to first create new overlay
> > files before we can safely delete the old overlay files in case the
> > creation fails so we have still recovery option when we error out.
> >
> > These new files will not have the suffix as when the snapshot was
> > created as renaming the original files in order to use the same file
> > names as when the snapshot was created would add unnecessary
> > complexity to the code.
> >
> > 2) When reverting to any snapshot we will always create overlay files
> > for every disk the VM had when the snapshot was done. Otherwise we
> > would have to figure out if there is any other qcow2 image already
> > using any of the VM disks as backing store and that itself might be
> > extremely complex and in some cases impossible.
> >
> > 3) When reverting from any state the current overlay files will be
> > always removed as that VM state is not meant to be saved. It's the
> > same as with internal snapshots. If user want's to keep the current
> > state before reverting they need to create a new snapshot. For now
> > this will only work if the current snapshot is the last.
> >
> > Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com>
> > ---
> > src/qemu/qemu_snapshot.c | 143 +++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 139 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c
> > index 9e4b978b1b..af4e2ea6aa 100644
> > --- a/src/qemu/qemu_snapshot.c
> > +++ b/src/qemu/qemu_snapshot.c
> > @@ -18,6 +18,8 @@
> >
> > #include <config.h>
> >
> > +#include <fcntl.h>
> > +
> > #include "qemu_snapshot.h"
> >
> > #include "qemu_monitor.h"
> > @@ -1968,6 +1970,119 @@ qemuSnapshotRevertWriteMetadata(virDomainObj *vm,
> > }
> >
> >
> > +static int
> > +qemuSnapshotRevertExternal(virDomainObj *vm,
> > + virDomainMomentObj *snap,
> > + virDomainDef *config,
> > + virDomainDef *inactiveConfig,
> > + int *memsnapFD,
> > + char **memsnapPath)
> > +{
> > + size_t i;
> > + virDomainDef *domdef = NULL;
> > + virDomainSnapshotLocation location =
VIR_DOMAIN_SNAPSHOT_LOCATION_EXTERNAL;
> > + virDomainMomentObj *curSnap =
virDomainSnapshotGetCurrent(vm->snapshots);
> > + virDomainSnapshotDef *snapdef = virDomainSnapshotObjGetDef(snap);
> > + virDomainSnapshotDef *curdef = virDomainSnapshotObjGetDef(curSnap);
> > + g_autoptr(virDomainSnapshotDef) tmpsnapdef = NULL;
> > + g_autoptr(virBitmap) created = NULL;
> > + int ret = -1;
> > +
> > + if (config) {
> > + domdef = config;
> > + } else {
> > + domdef = inactiveConfig;
> > + }
> > +
> > + if (!(tmpsnapdef = virDomainSnapshotDefNew()))
> > + return -1;
> > +
> > + if (virDomainMomentDefPostParse(&tmpsnapdef->parent) < 0)
>
> Weird at first glance. If we ever add something more to postparse that
> might be a wrong thing to call here. Add a comment here that it's needed
> _just_ for the timestamp stuff.
That works for me too.
I can probably just rename the function to reflect that it just
generates creation time and uses it as default name so in the future if
we need to add more post parse functionality we would have to create
true post parse function calling this renamed helper.
> > + return -1;
> > +
> > + if (virDomainSnapshotAlignDisks(tmpsnapdef, domdef, location, false) <
0)
> > + return -1;
>
> So in the end you do align the definition, thus the modification to the
> function you did should not be needed.
>
> You also seem to rely on the fact that this auto-selects all
> non-readonly disks for snapshot, but note that in case when the
> definition has VIR_DOMAIN_SNAPSHOT_LOCATION_NO for some disks they will
> not be selected. Having VIR_DOMAIN_SNAPSHOT_LOCATION_NO though doesn't
> mean that there isn't a snapshot of that disk as it can be overriden
> when specifying disks explicitly, and thus that image does have an
> overlay. Reverting in the way implemented here would thus invalidate the
> overlay. This contradicts point 2 from the commit message.
This should not be an issue as the tmpsnapdef is a new empty snapshot
definition so no disk should have VIR_DOMAIN_SNAPSHOT_LOCATION_NO.
This code should just take existing domain definition and fill in the
new empty snapshot definition with all disks the domain is currently
using and the domain definition is from the snapshot metadata that we
are reverting to. So this part should work correctly.
No I'm speaking about the default disk snapshot mode that is requested
in the *domain* disk configuration:
<disk snapshot='no'>
This configuration gets taken in case when the *snapshot* disk
configuration has no setting, which is this case.
> Also at this point this effectively limits all of this to work
on local
> files only as virDomainSnapshotDefAssignExternalNames works only on
> local files ...
>
> > +
> > + created = virBitmapNew(tmpsnapdef->ndisks);
> > +
> > + if (qemuSnapshotCreateQcow2Files(vm, domdef, tmpsnapdef, created, false)
< 0)
> > + return -1;
>
> ... thus this will for this very specific moment work. But since you'll
> most likely will be adding a proper revert API with XML which should
> allow reversion also for network disks this is limiting that work.
This should not be an issue and the fact we call
virDomainSnapshotDefAssignExternalNames actually helps us to not support
reverting to non-local disks as with the existing API it is not
possible. This function is also called unconditionally when creating
external snapshots so without providing correct XML it will also fail.
This is called only when creating external *inactive* snapshots. For
active snapshots we create/format the files using the qemu binary and
the 'blockdev-create' QMP command, which is fully featured.
Yes external inactive snapshots are not fully featured.
I'm mentioning this here because while it works with the old-style API
where you can't override the filenames and virDomainSnapshotDefAssignExternalNames
doesn't work on network storage if either of them were to change this
part would break.
As noted I'd prefer to keep the overlay creation done via
'blockdev-create' in all cases where possible.
I need to definitely remove all code that directly uses
disk->src->path
but we should be able to keep virDomainSnapshotAlignDisks as the same is
used when creating snapshot.