Re: [PATCH 4/4] qemuDomainGetStatsBlockExportDisk: Report stats also for helper images

On Mon, Nov 1, 2021 at 4:48 PM Peter Krempa wrote: > > Add stat entries also for the mirror destination and the backup job > scratch/target file. This is possible with '-blockdev' as we use unique > index for the entries. I wanted to ask about getting the allocation for mirror target disk and I

Re: [PATCH 2/4] qemustatusxml2xmldata: backup-pull: Add private data for scratch image

On Mon, Nov 1, 2021 at 4:48 PM Peter Krempa wrote: > > Signed-off-by: Peter Krempa > --- > tests/qemustatusxml2xmldata/backup-pull-in.xml | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/tests/qemustatusxml2xmldata/backup-pull-in.xml >

Re: [PATCH] qemuDomainChangeDiskLive: Modify 'startupPolicy' before changing source

On Mon, Sep 13, 2021 at 11:04 AM Peter Krempa wrote: > > On Fri, Sep 10, 2021 at 22:04:01 +0300, Nir Soffer wrote: > > On Fri, Sep 10, 2021 at 4:35 PM Peter Krempa wrote: > > > > > > We don't support all startup policies with all source types so to > > >

Re: [PATCH] qemuDomainChangeDiskLive: Modify 'startupPolicy' before changing source

On Fri, Sep 10, 2021 at 4:35 PM Peter Krempa wrote: > > We don't support all startup policies with all source types so to > correctly allow switching from a 'file' based cdrom with 'optional' > startup policy to a 'block' based one which doesn't support optional we > must update the startup

Re: [PATCH] qemu: blockjob: Transition into 'ready' state only from expected states

On Tue, Apr 20, 2021 at 2:45 PM Peter Krempa wrote: > > In certain rare occasions qemu can transition a block job which was > already 'ready' into 'standby' and then back. If this happens in the > following order libvirt will get confused about the actual job state: > > 1) the block copy job is

Re: [ovirt-devel] [ARM64] Possiblity to support oVirt on ARM64

On Sun, Jul 19, 2020 at 5:04 PM Zhenyu Zheng wrote: > > Hi oVirt, > > We are currently trying to make oVirt work on ARM64 platform, since I'm quite > new to oVirt community, I'm wondering what is the current status about ARM64 > support in the oVirt upstream, as I saw the oVirt Wikipedia page

Re: [PATCH 32/32] kbase: Add document outlining internals of incremental backup in qemu

On Mon, Jun 15, 2020 at 8:13 PM Peter Krempa wrote: > > Outline the basics and how to integrate with externally created > overlays. Other topics will continue later. Thanks, this is very helpful! > Signed-off-by: Peter Krempa > --- > docs/kbase.html.in| 3 + >

Re: [libvirt] [PATCH RFC 11/11] qemu: backup: Implement support for backup disk bitmap name configuration

On Fri, Dec 20, 2019 at 3:27 PM Peter Krempa wrote: > > Use the user-configured name of the bitmap when merging the appropriate > bitmaps for an excremental backup so that the user can see it as > configured. Additionally expose the default bitmap name if nothing is > configured. > >

Re: [libvirt] [PATCH RFC 10/11] qemu: backup: Implement support for backup disk export name configuration

On Fri, Dec 20, 2019 at 3:27 PM Peter Krempa wrote: > > Pass the exportname as configured when exporting the image via NBD and > fill it with the default if it's not configured. > > Signed-off-by: Peter Krempa > --- > src/qemu/qemu_backup.c | 5 - > 1 file changed, 4 insertions(+), 1

Re: [libvirt] [PATCH RFC 09/11] conf: backup: Allow configuration of names exported via NBD

On Fri, Dec 20, 2019 at 4:01 PM Daniel P. Berrangé wrote: > > On Fri, Dec 20, 2019 at 02:25:27PM +0100, Peter Krempa wrote: > > If users wish to use different name for exported disks or bitmaps > > the new fields allow to do so. Additionally they also document the > > current settings. > > Is

Re: [libvirt] [PATCH RFC 09/11] conf: backup: Allow configuration of names exported via NBD

On Fri, Dec 20, 2019 at 3:27 PM Peter Krempa wrote: > > If users wish to use different name for exported disks or bitmaps > the new fields allow to do so. Additionally they also document the > current settings. > > Signed-off-by: Peter Krempa > --- > docs/formatbackup.html.in

[libvirt] [PATCH python] spec: Build python2 package in fedora < 31

Since commit ee0cfbe65c5d (spec: Unconditionally build python2 on Fedora) python2-libvirt is not built on any Fedora version. Fix the spec to drop python2-libvirt on Fedora 31. Signed-off-by: Nir Soffer --- libvirt-python.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [libvirt] [PATCH v6 6/9] backup: Document new XML for backups

On Tue, Mar 26, 2019 at 8:14 AM Eric Blake wrote: ... > > + pull > + > + > + > + > ... > + > + > + unix > + > + > +

Re: [libvirt] [PATCH v4 0/8] bulk snapshot list/redefine (incremental backup saga)

On Wed, Mar 13, 2019 at 12:01 AM Eric Blake wrote: > On 3/12/19 4:52 PM, Eric Blake wrote: > > >> vm_checkpoints table > >> > >> - checkpoint_id: UUID > >> - parent: UUID > >> - vm_id: UUID > >> - creation_date: TIMESTAMP > >> > >> vm_checkpoint_disk_map table > >> - disk_id: UUID > >> -

Re: [libvirt] [PATCH v4 0/8] bulk snapshot list/redefine (incremental backup saga)

On Tue, Mar 12, 2019 at 11:52 PM Eric Blake wrote: > On 3/12/19 4:35 PM, Nir Soffer wrote: > > >>> We don't have a need to list or define snapshots since we managed > >> snapshots > >>> on oVirt side. > >>> We want an API to list and redefin

Re: [libvirt] [PATCH v4 0/8] bulk snapshot list/redefine (incremental backup saga)

On Tue, Mar 12, 2019 at 11:02 PM Eric Blake wrote: > On 3/12/19 3:29 PM, Nir Soffer wrote: > > >>> snapshots = > >> srcdom.ListAllSnapshots(libvirt.VIR_DOMAIN_SNAPSHOT_LIST_TOPOLOGICAL) > >>> for snapshot in snapshts: > >>> xml = snap

Re: [libvirt] [PATCH v4 0/8] bulk snapshot list/redefine (incremental backup saga)

On Tue, Mar 12, 2019 at 9:49 PM Eric Blake wrote: > On 3/12/19 1:10 PM, Daniel P. Berrangé wrote: > > On Mon, Mar 11, 2019 at 09:38:31PM -0500, Eric Blake wrote: > >> While looking at my work on incremental backups, Nir raised a good > >> point: if we want to recreate a set of known checkpoints

Re: [libvirt] [PATCH python v2] Fix handling of optional params in blockCopy()

On Mon, Mar 11, 2019 at 11:35 PM Nir Soffer wrote: > Commit 2b4bd07e0a22 (Add check for params, nparams being a dictionary) > changed the way the optional params argument is treated. If > libvirt.virDomain.blockCopy() is called without specifying params, > params is None, and the ca

[libvirt] [PATCH python v2] Fix handling of optional params in blockCopy()

This is wrong as params is defined as kwarg, breaking existing libvirt users like oVirt. Add a check for Py_None, so we accept either a dict or None and fail with TypeError with anything else. Resolves: https://bugzilla.redhat.com/1687114 Signed-off-by: Nir Soffer --- libvirt-override.c | 2 +- 1

[libvirt] [PATCH python] Fix handling of optional params in blockCopy()

This is wrong as params is defined as kwarg, breaking existing libvirt users like oVirt. Remove the check, restoring the previous behaviour. Resolves: https://bugzilla.redhat.com/1687114 Signed-off-by: Nir Soffer --- libvirt-override.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff

Re: [libvirt] [PATCH python] Fix handling of optional params in blockCopy()

On Mon, Mar 11, 2019 at 12:00 PM Daniel P. Berrangé wrote: > On Sun, Mar 10, 2019 at 03:03:25AM +0200, Nir Soffer wrote: > > Commit 2b4bd07e0a22 (Add check for params, nparams being a dictionary) > > changed the way the optional params argument is treated. If > > libvir

Re: [libvirt] [PATCH] qmp: Deprecate query-nodes option of query-blockstats

On Mon, Jan 28, 2019 at 6:13 PM Daniel P. Berrangé wrote: > On Mon, Jan 28, 2019 at 04:37:50PM +0100, Kevin Wolf wrote: > > Am 28.01.2019 um 16:15 hat Anton Kuchin geschrieben: > > > This option is broken since a6baa60807 in v2.9 and returns mostly > > > zeroes instead of real stats because

Re: [libvirt] Overview of libvirt incremental backup API, part 2 (incremental/differential pull mode)

On Fri, Oct 5, 2018 at 7:58 AM Eric Blake wrote: > On 10/4/18 12:05 AM, Eric Blake wrote: > > The following (long) email describes a portion of the work-flow of how > > my proposed incremental backup APIs will work, along with the backend > > QMP commands that each one executes. I will reply to

Re: [libvirt] [PATCH 4/8] backup: Document new XML for backups

On Wed, Jun 13, 2018 at 7:42 PM Eric Blake wrote: > Prepare for new checkpoint and backup APIs by describing the XML > that will represent a checkpoint. This is modeled heavily after > the XML for virDomainSnapshotPtr, since both represent a point in > time of the guest. But while a snapshot

Re: [libvirt] [PATCH 3/8] backup: Introduce virDomainCheckpointPtr

On Wed, Jun 13, 2018 at 7:42 PM 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 represent a

Re: [libvirt] [PATCH 2/8] backup: Document nuances between different state capture APIs

On Wed, Jun 13, 2018 at 7:42 PM Eric Blake wrote: > Upcoming patches will add support for incremental backups via > a new API; but first, we need a landing page that gives an > overview of capturing various pieces of guest state, and which > APIs are best suited to which tasks. >

Re: [libvirt] [PATCH 1/8] snapshots: Avoid term 'checkpoint' for full system snapshot

On Wed, Jun 13, 2018 at 7:42 PM Eric Blake wrote: > Upcoming patches plan to introduce virDomainCheckpointPtr as a new > object for use in incremental backups, along with documentation > how incremental backups differ from snapshots. But first, we need > to rename any existing mention of a

Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language

On Tue, Nov 28, 2017 at 9:44 AM Martin Kletzander wrote: > On Mon, Nov 20, 2017 at 04:57:56PM +, Daniel P. Berrange wrote: > >On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote: > >> On Mon, Nov 20, 2017 at 03:25:33PM +, Daniel P. Berrange wrote: > >>

[libvirt] [PATCH python] Unify whitespace around *_ALLOW_THREADS macros

Most of the code treats libvirt API calls as separate block, keeping one blank line before the LIBVIRT_BEGIN_ALLOW_THREAD, and one blank line after LIBVIRT_END_ALLOW_THREADS. Unify the whitespace so all calls wrapped with these macros are treated as a separate block. --- libvirt-override.c | 115

Re: [libvirt] [PATCH python] Release the GIL during virDomainGetMemoryStats

On Wed, Sep 27, 2017 at 6:05 PM Daniel P. Berrange <berra...@redhat.com> wrote: > On Tue, Sep 26, 2017 at 08:05:59PM +0300, Nir Soffer wrote: > > We discovered that the entire python process get stuck for about 30 > > seconds when calling virDomain.getMemoryStats(

[libvirt] [PATCH python] Release the GIL during virDomainGetMemoryStats

the call to avoid this unwanted blocking. Signed-off-by: Nir Soffer <nir...@gmail.com> --- libvirt-override.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libvirt-override.c b/libvirt-override.c index 9eba4ed..0e33afb 100644 --- a/libvirt-override.c +++ b/libvirt-override.c @@

Re: [libvirt] [ovirt-devel] [RFC][scale] new API for querying domains stats

- Original Message - From: Francesco Romani from...@redhat.com To: Daniel P. Berrange berra...@redhat.com Cc: libvir-list@redhat.com, de...@ovirt.org Sent: Wednesday, July 2, 2014 6:41:28 PM Subject: Re: [ovirt-devel] [libvirt] [RFC][scale] new API for querying domains stats