backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
/*
|
|
|
|
* virdomaincheckpointobjlist.c: handle a tree of checkpoint objects
|
|
|
|
* (derived from virdomainsnapshotobjlist.c)
|
|
|
|
*
|
|
|
|
* Copyright (C) 2006-2019 Red Hat, Inc.
|
|
|
|
* Copyright (C) 2006-2008 Daniel P. Berrange
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library. If not, see
|
|
|
|
* <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
|
|
|
#include "internal.h"
|
|
|
|
#include "virdomaincheckpointobjlist.h"
|
|
|
|
#include "checkpoint_conf.h"
|
|
|
|
#include "virlog.h"
|
|
|
|
#include "virerror.h"
|
|
|
|
#include "datatypes.h"
|
|
|
|
#include "virstring.h"
|
|
|
|
#include "viralloc.h"
|
|
|
|
|
|
|
|
#define VIR_FROM_THIS VIR_FROM_DOMAIN_CHECKPOINT
|
|
|
|
|
|
|
|
VIR_LOG_INIT("conf.virdomaincheckpointobjlist");
|
|
|
|
|
|
|
|
struct _virDomainCheckpointObjList {
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainMomentObjList *base;
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
};
|
|
|
|
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainMomentObj *
|
|
|
|
virDomainCheckpointAssignDef(virDomainCheckpointObjList *checkpoints,
|
|
|
|
virDomainCheckpointDef *def)
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
{
|
|
|
|
return virDomainMomentAssignDef(checkpoints->base, &def->parent);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static bool
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointFilter(virDomainMomentObj *obj G_GNUC_UNUSED,
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
unsigned int flags)
|
|
|
|
{
|
|
|
|
/* For now, we have no further filters than what the common code handles. */
|
|
|
|
virCheckFlags(0, false);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointObjList *
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
virDomainCheckpointObjListNew(void)
|
|
|
|
{
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointObjList *checkpoints;
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
|
2020-10-07 21:15:50 +02:00
|
|
|
checkpoints = g_new0(virDomainCheckpointObjList, 1);
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
checkpoints->base = virDomainMomentObjListNew();
|
|
|
|
if (!checkpoints->base) {
|
|
|
|
VIR_FREE(checkpoints);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
return checkpoints;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointObjListFree(virDomainCheckpointObjList *checkpoints)
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
{
|
|
|
|
if (!checkpoints)
|
|
|
|
return;
|
|
|
|
virDomainMomentObjListFree(checkpoints->base);
|
2021-01-30 14:05:50 -05:00
|
|
|
g_free(checkpoints);
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointObjListGetNames(virDomainCheckpointObjList *checkpoints,
|
|
|
|
virDomainMomentObj *from,
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
char **const names,
|
|
|
|
int maxnames,
|
|
|
|
unsigned int flags)
|
|
|
|
{
|
|
|
|
/* We intentionally chose our public flags to match the common flags */
|
2020-01-09 10:39:55 +00:00
|
|
|
G_STATIC_ASSERT(VIR_DOMAIN_CHECKPOINT_LIST_ROOTS ==
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
(int) VIR_DOMAIN_MOMENT_LIST_ROOTS);
|
2020-01-09 10:39:55 +00:00
|
|
|
G_STATIC_ASSERT(VIR_DOMAIN_CHECKPOINT_LIST_TOPOLOGICAL ==
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
(int) VIR_DOMAIN_MOMENT_LIST_TOPOLOGICAL);
|
2020-01-09 10:39:55 +00:00
|
|
|
G_STATIC_ASSERT(VIR_DOMAIN_CHECKPOINT_LIST_LEAVES ==
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
(int) VIR_DOMAIN_MOMENT_LIST_LEAVES);
|
2020-01-09 10:39:55 +00:00
|
|
|
G_STATIC_ASSERT(VIR_DOMAIN_CHECKPOINT_LIST_NO_LEAVES ==
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
(int) VIR_DOMAIN_MOMENT_LIST_NO_LEAVES);
|
|
|
|
|
|
|
|
return virDomainMomentObjListGetNames(checkpoints->base, from, names,
|
|
|
|
maxnames, flags,
|
|
|
|
virDomainCheckpointFilter, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainMomentObj *
|
|
|
|
virDomainCheckpointFindByName(virDomainCheckpointObjList *checkpoints,
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
const char *name)
|
|
|
|
{
|
|
|
|
return virDomainMomentFindByName(checkpoints->base, name);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Return the current checkpoint, or NULL */
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainMomentObj *
|
|
|
|
virDomainCheckpointGetCurrent(virDomainCheckpointObjList *checkpoints)
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
{
|
|
|
|
return virDomainMomentGetCurrent(checkpoints->base);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Return the current checkpoint's name, or NULL */
|
|
|
|
const char *
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointGetCurrentName(virDomainCheckpointObjList *checkpoints)
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
{
|
|
|
|
return virDomainMomentGetCurrentName(checkpoints->base);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Update the current checkpoint, using NULL if no current remains */
|
|
|
|
void
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointSetCurrent(virDomainCheckpointObjList *checkpoints,
|
|
|
|
virDomainMomentObj *checkpoint)
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
{
|
|
|
|
virDomainMomentSetCurrent(checkpoints->base, checkpoint);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Remove checkpoint from the list; return true if it was current */
|
|
|
|
bool
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointObjListRemove(virDomainCheckpointObjList *checkpoints,
|
|
|
|
virDomainMomentObj *checkpoint)
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
{
|
|
|
|
return virDomainMomentObjListRemove(checkpoints->base, checkpoint);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Remove all checkpoints tracked in the list */
|
|
|
|
void
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointObjListRemoveAll(virDomainCheckpointObjList *checkpoints)
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
{
|
|
|
|
return virDomainMomentObjListRemoveAll(checkpoints->base);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointForEach(virDomainCheckpointObjList *checkpoints,
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
virHashIterator iter,
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
return virDomainMomentForEach(checkpoints->base, iter, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Populate parent link of a given checkpoint. */
|
|
|
|
void
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointLinkParent(virDomainCheckpointObjList *checkpoints,
|
|
|
|
virDomainMomentObj *chk)
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
{
|
|
|
|
return virDomainMomentLinkParent(checkpoints->base, chk);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Populate parent link and child count of all checkpoints, with all
|
|
|
|
* assigned defs having relations starting as 0/NULL. Return 0 on
|
|
|
|
* success, -1 if a parent is missing or if a circular relationship
|
|
|
|
* was requested. Set leaf to the end of the chain, if there is
|
|
|
|
* exactly one such leaf. */
|
|
|
|
int
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointUpdateRelations(virDomainCheckpointObjList *checkpoints,
|
|
|
|
virDomainMomentObj **leaf)
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
{
|
|
|
|
int ret = virDomainMomentUpdateRelations(checkpoints->base);
|
|
|
|
|
|
|
|
if (ret == 0)
|
|
|
|
*leaf = virDomainMomentFindLeaf(checkpoints->base);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainCheckpointCheckCycles(virDomainCheckpointObjList *checkpoints,
|
|
|
|
virDomainCheckpointDef *def,
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
const char *domname)
|
|
|
|
{
|
|
|
|
return virDomainMomentCheckCycles(checkpoints->base, &def->parent, domname);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int
|
2021-03-11 08:16:13 +01:00
|
|
|
virDomainListCheckpoints(virDomainCheckpointObjList *checkpoints,
|
|
|
|
virDomainMomentObj *from,
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
virDomainPtr dom,
|
|
|
|
virDomainCheckpointPtr **chks,
|
|
|
|
unsigned int flags)
|
|
|
|
{
|
|
|
|
int count = virDomainCheckpointObjListGetNames(checkpoints, from, NULL,
|
|
|
|
0, flags);
|
|
|
|
virDomainCheckpointPtr *list = NULL;
|
|
|
|
char **names;
|
|
|
|
int ret = -1;
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
if (!chks || count < 0)
|
|
|
|
return count;
|
2020-10-07 21:15:50 +02:00
|
|
|
|
|
|
|
names = g_new0(char *, count);
|
|
|
|
list = g_new0(virDomainCheckpointPtr, count + 1);
|
backup: Allow for lists of checkpoint objects
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 21:24:54 -05:00
|
|
|
|
|
|
|
if (virDomainCheckpointObjListGetNames(checkpoints, from, names, count,
|
|
|
|
flags) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
for (i = 0; i < count; i++)
|
|
|
|
if ((list[i] = virGetDomainCheckpoint(dom, names[i])) == NULL)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
ret = count;
|
|
|
|
*chks = list;
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
for (i = 0; i < count; i++)
|
|
|
|
VIR_FREE(names[i]);
|
|
|
|
VIR_FREE(names);
|
|
|
|
if (ret < 0 && list) {
|
|
|
|
for (i = 0; i < count; i++)
|
|
|
|
virObjectUnref(list[i]);
|
|
|
|
VIR_FREE(list);
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|