Bjoern Walk [2019-03-25, 09:04AM +0100]:
> This patch series introduces the ability to save additional information
> for the domain state and exposes this information in virsh domstate.
>
> For example in the case of QEMU guest panic events, we can provide additional
> information like the crash
On 3/6/19 11:47 PM, Eric Blake wrote:
> The remote code generator had to be taught about the new
> virDomainCheckpointPtr type, at which point the remote driver
> code for backups can be generated.
>
> Signed-off-by: Eric Blake
> ---
Question for Dan:
> + /**
> + * @generate: both
> +
On 3/26/19 1:13 PM, Eric Blake wrote:
TL;DR:
After more thought, I'm reluctant to make a domain job an opaque type.
I'm also leaning towards withdrawing virDomainListJobIds() from the set
of APIs I'm proposing for 5.2, on the grounds that with a documented
magic job id of '0' that means "the
On 3/26/19 12:41 PM, Peter Krempa wrote:
> On Tue, Mar 26, 2019 at 01:13:44 -0500, Eric Blake wrote:
>> I'm fairly confident that these API are ready to go (that is, I've got
>> qemu code in the wings to implement these API for the qemu driver, as
>> demonstrated at last KVM forum, and it
On 3/26/19 12:08 PM, Daniel P. Berrangé wrote:
> On Tue, Mar 26, 2019 at 01:13:52AM -0500, Eric Blake wrote:
>> Introduce a few more new public APIs related to incremental backups.
>> This builds on the previous notion of a checkpoint (without an
>> existing checkpoint, the new API is a full
On 3/26/19 11:55 AM, Daniel P. Berrangé wrote:
> On Tue, Mar 26, 2019 at 01:13:51AM -0500, Eric Blake wrote:
>> 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),
On Tue, Mar 26, 2019 at 01:13:44 -0500, Eric Blake wrote:
> I'm fairly confident that these API are ready to go (that is, I've got
> qemu code in the wings to implement these API for the qemu driver, as
> demonstrated at last KVM forum, and it shouldn't be too hard to add
> support in the test
On 3/26/19 12:58 PM, Ján Tomko wrote:
On Mon, Mar 25, 2019 at 01:24:32PM -0400, Laine Stump wrote:
This function can be called with a virDomainDevicePtr and whether or
not the removal was successful, and it will call the appropriate
virDomainAudit*() function with the appropriate args for
On Tue, Mar 26, 2019 at 06:01:49PM +0100, Andrea Bolognani wrote:
> Running QEMU as root is a pretty bad idea, so try to make the
> user aware of that as part of the configure summary.
>
> Signed-off-by: Andrea Bolognani
> ---
> m4/virt-driver-qemu.m4 | 7 ++-
> 1 file changed, 6
On Tue, Mar 26, 2019 at 06:01:48PM +0100, Andrea Bolognani wrote:
> Our current defaults are root:wheel on FreeBSD and macOS, root:root
> everywhere else.
>
> Looking at what downstream distributions actually do, we can see that
> these defaults are overriden the vast majority of the time, with a
On Tue, Mar 26, 2019 at 01:13:53AM -0500, Eric Blake wrote:
> Now that various new API have been added, 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:
On Tue, Mar 26, 2019 at 01:13:49AM -0500, Eric Blake wrote:
> 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
On Tue, Mar 26, 2019 at 01:13:50AM -0500, Eric Blake wrote:
> Prepare for new backup APIs by describing the XML that will represent
> a backup. The XML resembles snapshots and checkpoints in being able
> to select actions for a set of disks, but has other differences. It
> can support both push
On Tue, Mar 26, 2019 at 01:13:48AM -0500, Eric Blake wrote:
> Prepare for introducing a bunch of new public APIs related to
> backup checkpoints by first introducing a new internal type
> and errors associated with that type. Checkpoints are modeled
> heavily after virDomainSnapshotPtr (both
On Tue, Mar 26, 2019 at 01:13:47AM -0500, Eric Blake wrote:
> Since I was copying this text to form checkpoint XML and API
> documentation, I might as well make improvements along the way. Most
> of these changes are based on reviews of the checkpoint docs.
>
> Among other things: grammar tweaks,
On Tue, Mar 26, 2019 at 01:13:46AM -0500, Eric Blake wrote:
> This reverts commit 86c0ed6f70268dfa7c3bba95a0ba96fcfe2ab039, and
> subsequent refactorings of the function into new files. There are no
> callers of this function - I had originally proposed it for
> implementing a new bulk snapshot
On Tue, Mar 26, 2019 at 01:13:45AM -0500, Eric Blake wrote:
> This reverts commit 1b57269cbcfcfe998a065c0c9f0f8db408710d87, and
> subsequent refactorings of the function into new files. There are no
> callers of this function - I had originally proposed it for
> implementing a new bulk snapshot
On Tue, Mar 26, 2019 at 01:13:52AM -0500, Eric Blake wrote:
> Introduce a few more new public APIs related to incremental backups.
> This builds on the previous notion of a checkpoint (without an
> existing checkpoint, the new API is a full backup, differing from
> virDomainBlockCopy in the point
Changes from [v2]:
* add explicit fallback to root:root for unrecognized operating
systems;
* provide logging to help users understand why they ended up with
root:root in the first place.
Changes from [v1]:
* use distro-specific user and group;
* warn the user if they are
On Tue, Mar 26, 2019 at 01:15:33PM +0100, Peter Krempa wrote:
On Mon, Mar 25, 2019 at 13:24:35 -0400, Laine Stump wrote:
+return -1;
+}
+info = NULL; /* to prevent accidental use later */
// this is bridge [1]
+
switch ((virDomainDeviceType)dev->type) {
ACK with the
Our current defaults are root:wheel on FreeBSD and macOS, root:root
everywhere else.
Looking at what downstream distributions actually do, we can see that
these defaults are overriden the vast majority of the time, with a
number of variations showing up in the wild:
* qemu:qemu -> Used by
Running QEMU as root is a pretty bad idea, so try to make the
user aware of that as part of the configure summary.
Signed-off-by: Andrea Bolognani
---
m4/virt-driver-qemu.m4 | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/m4/virt-driver-qemu.m4 b/m4/virt-driver-qemu.m4
On Tue, 2019-03-26 at 16:20 +, Daniel P. Berrangé wrote:
> On Tue, Mar 26, 2019 at 05:06:15PM +0100, Andrea Bolognani wrote:
> > +# Try to integrate gracefully with downstream packages by running QEMU
> > +# processes under the same user and group they would
> > +case $(grep ^ID=
On Mon, Mar 25, 2019 at 01:24:32PM -0400, Laine Stump wrote:
This function can be called with a virDomainDevicePtr and whether or
not the removal was successful, and it will call the appropriate
virDomainAudit*() function with the appropriate args for whatever type
of device it's given (or do
On Tue, Mar 26, 2019 at 01:13:51AM -0500, Eric Blake wrote:
> 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
On Tue, Mar 26, 2019 at 01:13:46AM -0500, Eric Blake wrote:
This reverts commit 86c0ed6f70268dfa7c3bba95a0ba96fcfe2ab039, and
subsequent refactorings of the function into new files. There are no
callers of this function - I had originally proposed it for
implementing a new bulk snapshot API,
On Tue, Mar 26, 2019 at 01:13:45AM -0500, Eric Blake wrote:
This reverts commit 1b57269cbcfcfe998a065c0c9f0f8db408710d87, and
subsequent refactorings of the function into new files. There are no
callers of this function - I had originally proposed it for
implementing a new bulk snapshot API,
osinfo-db tests are Python3 only.
Signed-off-by: Fabiano Fidêncio
---
guests/playbooks/build/projects/osinfo-db.yml | 13 +
jenkins/projects/osinfo-db.yaml | 9 +
2 files changed, 22 insertions(+)
diff --git a/guests/playbooks/build/projects/osinfo-db.yml
The new dependencies are:
- python3
- python3-lxml
- python3-pytest
- python3-requests
xmllint has been removed in favour of a own crafted test using
python3-lxml
Signed-off-by: Fabiano Fidêncio
---
guests/vars/projects/osinfo-db.yml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
On Tue, Mar 26, 2019 at 04:24:00PM +, Daniel P. Berrangé wrote:
On Tue, Mar 26, 2019 at 05:06:16PM +0100, Andrea Bolognani wrote:
Running QEMU as root is a pretty bad idea, so try to make the
user aware of that as part of the configure summary.
Signed-off-by: Andrea Bolognani
---
On Tue, Mar 26, 2019 at 05:06:16PM +0100, Andrea Bolognani wrote:
> Running QEMU as root is a pretty bad idea, so try to make the
> user aware of that as part of the configure summary.
>
> Signed-off-by: Andrea Bolognani
> ---
> m4/virt-driver-qemu.m4 | 7 ++-
> 1 file changed, 6
On Tue, Mar 26, 2019 at 05:06:15PM +0100, Andrea Bolognani wrote:
> Our current defaults are root:wheel on FreeBSD and macOS, root:root
> everywhere else.
>
> Looking at what downstream distributions actually do, we can see that
> these defaults are overriden the vast majority of the time, with a
Running QEMU as root is a pretty bad idea, so try to make the
user aware of that as part of the configure summary.
Signed-off-by: Andrea Bolognani
---
m4/virt-driver-qemu.m4 | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/m4/virt-driver-qemu.m4 b/m4/virt-driver-qemu.m4
Changes from [v1]:
* use distro-specific user and group;
* warn the user if they are going to be running QEMU as root.
[v1] https://www.redhat.com/archives/libvir-list/2019-March/msg01707.html
Andrea Bolognani (2):
m4: Run QEMU under a distro-specific user when possible
m4: Add warning
Our current defaults are root:wheel on FreeBSD and macOS, root:root
everywhere else.
Looking at what downstream distributions actually do, we can see that
these defaults are overriden the vast majority of the time, with a
number of variations showing up in the wild:
* qemu:qemu -> Used by
On Tue, Mar 26, 2019 at 04:20:02PM +0100, Pavel Hrdina wrote:
> On Tue, Mar 26, 2019 at 01:36:14PM +, Daniel P. Berrangé wrote:
> > On Tue, Mar 26, 2019 at 02:30:00PM +0100, Pavel Hrdina wrote:
> > > On Tue, Mar 26, 2019 at 01:20:46PM +, Daniel P. Berrangé wrote:
> > > > On Tue, Mar 26,
On Tue, Mar 26, 2019 at 01:36:14PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 26, 2019 at 02:30:00PM +0100, Pavel Hrdina wrote:
> > On Tue, Mar 26, 2019 at 01:20:46PM +, Daniel P. Berrangé wrote:
> > > On Tue, Mar 26, 2019 at 12:49:28PM +0100, Andrea Bolognani wrote:
> > > > Our current
On Tue, Mar 26, 2019 at 03:40:12PM +0100, Martin Kletzander wrote:
> On Mon, Mar 25, 2019 at 03:48:59PM +, Daniel P. Berrangé wrote:
> > On Mon, Mar 25, 2019 at 04:12:34PM +0100, Martin Kletzander wrote:
> > > On Mon, Mar 25, 2019 at 10:03:31AM +0100, Peter Krempa wrote:
> > > > On Mon, Mar
On Mon, Mar 25, 2019 at 03:48:59PM +, Daniel P. Berrangé wrote:
On Mon, Mar 25, 2019 at 04:12:34PM +0100, Martin Kletzander wrote:
On Mon, Mar 25, 2019 at 10:03:31AM +0100, Peter Krempa wrote:
> On Mon, Mar 25, 2019 at 09:15:23 +0100, Erik Skultety wrote:
> > On Mon, Mar 25, 2019 at
On Tue, 2019-03-26 at 13:37 +, Daniel P. Berrangé wrote:
> On Tue, Mar 26, 2019 at 02:30:33PM +0100, Andrea Bolognani wrote:
> > > If we want to change this, we must ensure that we honour the distro
> > > specific user/group names you show above, and fallback to root/root
> > > for distros we
On 3/26/19 8:52 AM, Peter Krempa wrote:
On Mon, Mar 25, 2019 at 13:24:33 -0400, Laine Stump wrote:
Although all hotpluggable devices other than lease, controller,
watchdof, and vsock can be audited, and *are* audited when an unplug
is successful, only disk, net, and hostdev were actually being
On 3/26/19 3:45 AM, Peter Krempa wrote:
On Mon, Mar 25, 2019 at 13:24:25 -0400, Laine Stump wrote:
qemuDomainDetachDeviceLive() is called from two places in
qemu_driver.c, and qemuDomainUpdateDeviceList() is called from the
end of qemuDomainDetachDeviceLive(), which is now in qemu_hotplug.c
On 3/26/19 8:40 AM, Peter Krempa wrote:
On Mon, Mar 25, 2019 at 13:24:30 -0400, Laine Stump wrote:
Most of these functions will soon contain only some setup for
detaching the device, not the detach code proper (since that code is
identical for these devices). Their device specific functions are
It's time to get a new release out. Simplest would be to enter freeze
tomorrow, then we can plan an RC2 by Friday, and if everything looks
good have the release on time next Monday.
Hope this works for everybody,
thanks,
Daniel
--
Daniel Veillard | Red Hat Developers Tools
On Tue, Mar 26, 2019 at 02:30:33PM +0100, Andrea Bolognani wrote:
> On Tue, 2019-03-26 at 13:20 +, Daniel P. Berrangé wrote:
> > On Tue, Mar 26, 2019 at 12:49:28PM +0100, Andrea Bolognani wrote:
> > > Our current defaults are root:wheel on FreeBSD and macOS, root:root
> > > everywhere else.
>
On Tue, Mar 26, 2019 at 02:30:00PM +0100, Pavel Hrdina wrote:
> On Tue, Mar 26, 2019 at 01:20:46PM +, Daniel P. Berrangé wrote:
> > On Tue, Mar 26, 2019 at 12:49:28PM +0100, Andrea Bolognani wrote:
> > > Our current defaults are root:wheel on FreeBSD and macOS, root:root
> > > everywhere else.
On Tue, 2019-03-26 at 13:20 +, Daniel P. Berrangé wrote:
> On Tue, Mar 26, 2019 at 12:49:28PM +0100, Andrea Bolognani wrote:
> > Our current defaults are root:wheel on FreeBSD and macOS, root:root
> > everywhere else.
> >
> > Looking at what downstream distributions actually do, we can see
On Tue, Mar 26, 2019 at 01:20:46PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 26, 2019 at 12:49:28PM +0100, Andrea Bolognani wrote:
> > Our current defaults are root:wheel on FreeBSD and macOS, root:root
> > everywhere else.
> >
> > Looking at what downstream distributions actually do, we can
On Tue, Mar 26, 2019 at 12:49:28PM +0100, Andrea Bolognani wrote:
> Our current defaults are root:wheel on FreeBSD and macOS, root:root
> everywhere else.
>
> Looking at what downstream distributions actually do, we can see that
> these defaults are overriden the vast majority of the time, with a
On Mon, Mar 25, 2019 at 13:24:36 -0400, Laine Stump wrote:
> For [some unknown reason, possibly/probably pure chance], Net devices
> have been taken offline and their bandwidth tc rules cleared as the
> very first operation when detaching the device. This is contrary to
> every other type of
On Mon, Mar 25, 2019 at 13:24:34 -0400, Laine Stump wrote:
> Now that all the qemuDomainDetachPrep*() functions look nearly
> identical at the end, we can put one copy of that identical code in
> qemuDomainDetachDeviceLive() at the point after the individual prep
> functions have been called, and
On Mon, Mar 25, 2019 at 13:24:33 -0400, Laine Stump wrote:
> Although all hotpluggable devices other than lease, controller,
> watchdof, and vsock can be audited, and *are* audited when an unplug
> is successful, only disk, net, and hostdev were actually being audited
> on failure.
>
> This patch
On Tue, 2019-03-26 at 13:03 +0100, Peter Krempa wrote:
> Remove some dead code.
>
> Peter Krempa (2):
> qemu: Assume that 'set_password' and 'expire_password' are supported
> qemu: monitor: Remove unused qemuMonitor(JSON)SetVNCPassword
>
> src/qemu/qemu_hotplug.c | 20
On Mon, Mar 25, 2019 at 13:24:32 -0400, Laine Stump wrote:
> This function can be called with a virDomainDevicePtr and whether or
> not the removal was successful, and it will call the appropriate
> virDomainAudit*() function with the appropriate args for whatever type
> of device it's given (or
On Mon, Mar 25, 2019 at 13:24:31 -0400, Laine Stump wrote:
> qemuDomainDetachDeviceChr and qemuDomainDetachDeviceLease are more
> consistent with each other.
>
> Signed-off-by: Laine Stump
> ---
>
> NEW PATCH in V2 (previously was part of 08/14)
>
> src/qemu/qemu_hotplug.c | 12 ++--
>
On Mon, Mar 25, 2019 at 13:24:30 -0400, Laine Stump wrote:
> Most of these functions will soon contain only some setup for
> detaching the device, not the detach code proper (since that code is
> identical for these devices). Their device specific functions are all
> being renamed to
On Tue, Mar 26, 2019 at 01:03:04PM +0100, Peter Krempa wrote:
Signed-off-by: Peter Krempa
---
src/qemu/qemu_monitor.c | 15 ---
src/qemu/qemu_monitor.h | 2 --
src/qemu/qemu_monitor_json.c | 25 -
src/qemu/qemu_monitor_json.h | 2 --
On Tue, Mar 26, 2019 at 01:03:03PM +0100, Peter Krempa wrote:
They were added in qemu commit 7572150c189c6553c2448334116ab717680de66d
released in v0.14.0.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_hotplug.c | 20
src/qemu/qemu_monitor.c | 1 -
On Mon, Mar 25, 2019 at 13:24:35 -0400, Laine Stump wrote:
> The VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED event is sent after qemu has
> responded to a device_del command with a DEVICE_DELETED event. Before
> queuing the event, *some* of the final teardown of the device's
> trappings in libvirt is done,
Signed-off-by: Peter Krempa
---
src/qemu/qemu_monitor.c | 15 ---
src/qemu/qemu_monitor.h | 2 --
src/qemu/qemu_monitor_json.c | 25 -
src/qemu/qemu_monitor_json.h | 2 --
tests/qemumonitorjsontest.c | 2 --
5 files changed, 46 deletions(-)
diff
Remove some dead code.
Peter Krempa (2):
qemu: Assume that 'set_password' and 'expire_password' are supported
qemu: monitor: Remove unused qemuMonitor(JSON)SetVNCPassword
src/qemu/qemu_hotplug.c | 20 ---
src/qemu/qemu_monitor.c | 16
They were added in qemu commit 7572150c189c6553c2448334116ab717680de66d
released in v0.14.0.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_hotplug.c | 20
src/qemu/qemu_monitor.c | 1 -
src/qemu/qemu_monitor_json.c | 12
3 files changed, 33
On Tue, 2019-03-26 at 11:29 +0100, Fabiano Fidêncio wrote:
[...]
> jenkins/projects/osinfo-db.yaml | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
You need to update the corresponding file living under
guests/playbooks/build/ at the same time.
[...]
> - project:
>
On Tue, 2019-03-19 at 16:33 +0100, Fabiano Fidêncio wrote:
> The new dependencies are:
> - python3
> - python3-libxml2
> - python3-pytest
> - python3-requests
>
> xmllint has been removed in favour of a own crafted test using
> python3-libmlx2
>
> Signed-off-by: Fabiano Fidêncio
> ---
Our current defaults are root:wheel on FreeBSD and macOS, root:root
everywhere else.
Looking at what downstream distributions actually do, we can see that
these defaults are overriden the vast majority of the time, with a
number of variations showing up in the wild:
* qemu:qemu -> Used by
osinfo-db tests are Python3 only.
Signed-off-by: Fabiano Fidêncio
---
jenkins/projects/osinfo-db.yaml | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/jenkins/projects/osinfo-db.yaml b/jenkins/projects/osinfo-db.yaml
index 87b6748..25a6621 100644
---
On Tue, 2019-03-26 at 09:02 +0100, Michal Privoznik wrote:
> If qemuFirmwareFetchConfigs() returned more or less paths than
https://66.media.tumblr.com/c9eb5611a9f9c6a5cb7be6d5365afdf9/tumblr_ouaw1xYO8u1ruwssto2_500.gif
> expected all that we see is the following error message:
>
> Expected 5
On Mon, Mar 25, 2019 at 13:24:29 -0400, Laine Stump wrote:
> The Chr and Lease devices have detach code that is too different from
> the other device types to handle with common functionality (which will
> soon be added at the end of qemuDomainDetachDeviceLive(). In order to
> make this difference
On Mon, Mar 25, 2019 at 13:24:28 -0400, Laine Stump wrote:
> I'm about to add a second virDomainDeviceDef to this function that
> will point to the actual device in the domain object. "dev" is
> just a partially filled-in example of what to look for. Naming it
> match will make the code easier to
If qemuFirmwareFetchConfigs() returned more or less paths than
expected all that we see is the following error message:
Expected 5 paths, got 7
While it is technically correct (the best kind of correct), we
can do better:
Unexpected path (i=0). Expected /some/path got /some/other/path
On Mon, Mar 25, 2019 at 13:24:27 -0400, Laine Stump wrote:
> These are no longer called from qemu_driver.c, since the function that
> called them (qemuDomainDetachDeviceLive()) has been moved to
> qemu_hotplug.c, and they are no longer called from testqemuhotplug.c
> because it now just called
On Mon, Mar 25, 2019 at 13:24:26 -0400, Laine Stump wrote:
> The individual qemuDomainDetach*Device() functions will soon be "less
> functional", since some of the code that is duplicated in 10 of the 12
> detach functions is going to be moved into the common
> qemuDomainDetachDeviceLive(), which
On Mon, Mar 25, 2019 at 13:24:25 -0400, Laine Stump wrote:
> qemuDomainDetachDeviceLive() is called from two places in
> qemu_driver.c, and qemuDomainUpdateDeviceList() is called from the
> end of qemuDomainDetachDeviceLive(), which is now in qemu_hotplug.c
>
> This patch replaces the single call
On Mon, Mar 25, 2019 at 13:24:24 -0400, Laine Stump wrote:
> qemuDomainDetachDeviceControllerLive() just checks if the controller
> type is SCSI, and then either returns failure, or calls
> qemuDomainDetachControllerDevice().
>
> Instead, lets just check for type != SCSI at the top of the latter
On Mon, Mar 25, 2019 at 13:24:23 -0400, Laine Stump wrote:
> This function is going to take on some of the functionality of its
> subordinate functions, which all live in qemu_hotplug.c.
>
> qemuDomainDetachDeviceControllerLive() is only called from
> qemuDomainDetachDeviceLive() (and will soon
Prepare for introducing a bunch of new public APIs related to
backup checkpoints by first introducing a new internal type
and errors associated with that type. Checkpoints are modeled
heavily after virDomainSnapshotPtr (both represent a point in
time of the guest), although a snapshot exists with
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
This reverts commit 86c0ed6f70268dfa7c3bba95a0ba96fcfe2ab039, and
subsequent refactorings of the function into new files. There are no
callers of this function - I had originally proposed it for
implementing a new bulk snapshot API, but that proved to be too
invasive given RPC limits. I also
Introduce a few more new public APIs related to incremental backups.
This builds on the previous notion of a checkpoint (without an
existing checkpoint, the new API is a full backup, differing from
virDomainBlockCopy in the point of time chosen and in operation on
multiple disks at once); and also
Now that various new API have been added, 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
---
docs/docs.html.in | 5 +
Prepare for new backup APIs by describing the XML that will represent
a backup. The XML resembles snapshots and checkpoints in being able
to select actions for a set of disks, but has other differences. It
can support both push model (the hypervisor does the backup directly
into the destination
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.
Signed-off-by: Eric Blake
---
docs/docs.html.in
Since I was copying this text to form checkpoint XML and API
documentation, I might as well make improvements along the way. Most
of these changes are based on reviews of the checkpoint docs.
Among other things: grammar tweaks, point to a single source of
documentation rather than repeating
I'm fairly confident that these API are ready to go (that is, I've got
qemu code in the wings to implement these API for the qemu driver, as
demonstrated at last KVM forum, and it shouldn't be too hard to add
support in the test driver to get some 'make check' coverage similar
to what I recently
This reverts commit 1b57269cbcfcfe998a065c0c9f0f8db408710d87, and
subsequent refactorings of the function into new files. There are no
callers of this function - I had originally proposed it for
implementing a new bulk snapshot API, but that proved to be too
invasive given RPC limits. I also
85 matches
Mail list logo
