A lot of this work heavily copies from the existing snapshot APIs.
The test driver doesn't really have to do anything more than just
expose an interface into libvirt metadata, making it possible to test
saving and restoring XML, and tracking relations between multiple
checkpoints.
Signed-off-by: E
The remote code generator had to be taught about the new
virDomainCheckpointPtr type, at which point the remote driver code for
checkpoints can be generated.
Signed-off-by: Eric Blake
Reviewed-by: Daniel P. Berrangé
---
src/remote/remote_daemon_dispatch.c | 20 +
src/remote/remote_driver.c
Time to actually issue the QMP transactions that create and
delete persistent checkpoints. For create, we only need one
transaction: inside, we visit all disks affected by the
checkpoint, and create a new enabled bitmap, as well as
disabling the bitmap of the parent checkpoint (if any). For
delet
Similar to virsh-snapshots (which also gets a minor tweak, to prove we
properly lock out one API from the other until later integration
efforts figure out the best way to proceed). Provides decent coverage
of the checkpoint API, the test driver implementation, and the virsh
access to the API.
Sign
It is possible, but tedious, to tell if a checkpoint is current by
parsing XML. As this operation may be performed with some frequency,
it is worth an additional API (comparable to the existing
virDomainCheckpointGetParent that duplicates what can be learned from
XML, or the counterpart virDomainSn
A lot of this work heavily copies from the existing snapshot
APIs. The interaction with qemu during create/delete still
needs to be implemented, but this takes care of all the libvirt
metadata (saving and restoring XML, and tracking the relations
between multiple checkpoints).
Signed-off-by: Eric
Introduce a bunch of new virsh commands for managing checkpoints in
isolation. More commands are needed for performing incremental
backups, but these commands were easy to implement by modeling heavily
after virsh-snapshot.c. There is no need for checkpoint-revert or
checkpoint-current since those
Creating a checkpoint does not modify guest-visible state,
but does modify host resources. Rather than reuse existing
domain:write, domain:block_write, or domain:snapshot access
controls, it seems better to introduce a new access control
specific to tasks related to checkpoints and incremental
bac
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while checkpoints definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, the
This is a subset of v9 of incremental backup, fixing most of the
review comments that Peter gave on v8.5. The qemu portions in
patch 11 and 12 could probably still use some cleanups to address
feedback in v8 and v8.5; and I also intend to post a followup
series for the backup APIs on Monday to form
Prepare for new checkpoint APIs by describing the XML that will
represent a checkpoint. The checkpoint XML is modeled heavily after
virDomainSnapshotPtr. See the docs for more details.
Add testsuite coverage for some minimal uses of the XML (bare minimum,
the sample from html, and a full dumpxml)
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the
Introduce a bunch of new public APIs related to backup checkpoints.
Checkpoints are modeled heavily after virDomainSnapshotPtr (both
represent a point in time of the guest), although a snapshot exists
with the intent of rolling back to that state, while a checkpoint
exists to make it possible to cr
Now that various new API have been added or are coming soon, it is
worth a landing page that gives an overview of capturing various
pieces of guest state, and which APIs are best suited to which tasks.
Signed-off-by: Eric Blake
Reviewed-by: John Ferlan
Reviewed-by: Daniel P. Berrangé
---
docs/
On 4/17/19 9:09 AM, Eric Blake wrote:
> Accept XML describing a generic block job, and output it again as
> needed. This may still need a few tweaks to match the documented XML
> and RNG schema.
>
> Signed-off-by: Eric Blake
> ---
> +/* Align def->disks to domain. Sort the list of def->disks,
>
On Sat, Jul 6, 2019 at 1:24 PM Ilias Stamatis wrote:
>
> Signed-off-by: Ilias Stamatis
> ---
> src/test/test_driver.c | 97 ++
> 1 file changed, 97 insertions(+)
>
> diff --git a/src/test/test_driver.c b/src/test/test_driver.c
> index 7dd448bb20..fd57c8c57
Signed-off-by: Ilias Stamatis
---
src/test/test_driver.c | 97 ++
1 file changed, 97 insertions(+)
diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 7dd448bb20..fd57c8c572 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@
17 matches
Mail list logo
