Re: [libvirt] [PATCH] src: Include $(builddir)/util in the header search path

On Fri, Oct 09, 2015 at 09:41:48AM +0200, Andrea Bolognani wrote: On Thu, 2015-10-08 at 18:12 +0100, Daniel P. Berrange wrote: On Thu, Oct 08, 2015 at 06:55:23PM +0200, Andrea Bolognani wrote: > Since a9fe620372144db, we are generating virkeymaps.h at build > time; however, we are not including

Re: [libvirt] Cannot dump core: error: Requested operation is not valid: domain is marked for auto destroy

On Thu, Oct 08, 2015 at 12:36:29PM +0100, Richard W.M. Jones wrote: > Apparently not on aarch64 however: > > $ ~/d/libvirt/run ~/d/libvirt/tools/virsh dump --memory-only > guestfs-b1rs92hpq4izkpvi /tmp/guestfs-b1rs92hpq4izkpvi.core > error: Failed to core dump domain guestfs-b1rs92hpq4izkpvi to

Re: [libvirt] [PATCH] src: Include $(builddir)/util in the header search path

On Fri, Oct 09, 2015 at 09:41:48AM +0200, Andrea Bolognani wrote: On Thu, 2015-10-08 at 18:12 +0100, Daniel P. Berrange wrote: On Thu, Oct 08, 2015 at 06:55:23PM +0200, Andrea Bolognani wrote: > Since a9fe620372144db, we are generating virkeymaps.h at build > time; however, we are not including

[libvirt] [PATCH] Use correct pci addresses during device-detach

From: Nitesh_Konkar The attach-device on live and persistent copies can be done independently. Thus devices can end up having different pci addresses in live and persistent copies. The detach device should try to detach the device from their respective addresses instead

Re: [libvirt] [PATCH] src: Include $(builddir)/util in the header search path

On 08.10.2015 18:55, Andrea Bolognani wrote: > Since a9fe620372144db, we are generating virkeymaps.h at build > time; however, we are not including $(builddir)/util in the > header search path, so when doing a VPATH build the compiler > is unable to locate the file. > > make[2]: Entering

Re: [libvirt] [PATCH] src: Include $(builddir)/util in the header search path

On Thu, 2015-10-08 at 18:12 +0100, Daniel P. Berrange wrote: > On Thu, Oct 08, 2015 at 06:55:23PM +0200, Andrea Bolognani wrote: > > Since a9fe620372144db, we are generating virkeymaps.h at build > > time; however, we are not including $(builddir)/util in the > > header search path, so when doing

Re: [libvirt] [PATCH] src: Include $(builddir)/util in the header search path

On Fri, 2015-10-09 at 10:15 +0200, Martin Kletzander wrote: > Oh, byt he way, builddir is not a variable here (and not even > anywhere > else I believe), it's basically just the CWD (or PWD if you like), so > we might need to do this on top: > > diff --git i/src/Makefile.am w/src/Makefile.am >

Re: [libvirt] [PATCH] src: Remove $(builddir) usage

On Fri, Oct 09, 2015 at 01:06:32PM +0200, Andrea Bolognani wrote: Commit 4e8032272f1704f7 used $(builddir) in the header search path to fix a build issue; however, $(builddir) is not defined by old autoconf versions such as the one available in CentOS 5, resulting in the following error: cc1:

Re: [libvirt] [PATCH] virJSONValueArraySize: return ssize_t

On Thu, Oct 08, 2015 at 10:33:01AM +0200, Michal Privoznik wrote: > The internal representation of a JSON array counts the items in > size_t. However, for some reason, when asking for the count it's > reported as int. Firstly, we need the function to return a signed > type as it's returning -1 on

[libvirt] [PATCH] Use correct pci addresses during device-detach

From: Nitesh_Konkar The attach-device on live and persistent copies can be done independently. Thus devices can end up having different pci addresses in live and persistent copies. The detach device should try to detach the device from their respective addresses instead

Re: [libvirt] [PATCH] src: Remove $(builddir) usage

On Fri, 2015-10-09 at 14:26 +0200, Martin Kletzander wrote: > You could've also define the builddir at the top of the makefile as > we > do for abs_ variants of variables for older auto* which don't have > them. Look at me, I'm saying it like there's a difference. The value of $(abs_*dir) is

Re: [libvirt] [PATCH v4 0/12] migration: support all toURI and proto combos

On Fri, Oct 09, 2015 at 13:32:19 +0300, Nikolay Shirokovskiy wrote: > Guys, please take a look at the new version. Sure, I already started looking at it yesterday evening. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/2] util: Produce friendlier error message to user

On 10/08/2015 05:12 AM, lhuang wrote: > > > On 10/02/2015 11:54 PM, John Ferlan wrote: >> >> On 09/30/2015 12:01 AM, Luyao Huang wrote: >>> Commit 1c24cfe9 fix the problem in virNumaSetPagePoolSize, >>> this patch just like it and fix the issue in another function. >>> >>> when user use

Re: [libvirt] [PATCH v4 0/12] migration: support all toURI and proto combos

Guys, please take a look at the new version. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] src: Remove $(builddir) usage

Commit 4e8032272f1704f7 used $(builddir) in the header search path to fix a build issue; however, $(builddir) is not defined by old autoconf versions such as the one available in CentOS 5, resulting in the following error: cc1: error: /util: No such file or directory make[3]: ***

[libvirt] [PATCH 05/12] storage: On error unlink created file in virFileOpen{As|Forked}

After a successful creation of a file, if some other call results in returning a failure, let's unlink the file we created to prevent another round trip or confusion in the caller. In particular, this function can be called during a storage backend buildVol, so in order to ensure that caller

[libvirt] [PATCH 04/12] storage: Track successful creation of LV for removal

https://bugzilla.redhat.com/show_bug.cgi?id=1233003 Track when the logical volume was successfully created in order to properly handle the call to virStorageBackendLogicalDeleteVol. It's possible that the failure to create was because someone created an LV in the pool outside of libvirt's

[libvirt] [PATCH 08/12] storage: Cleanup failures virStorageBackendCreateExecCommand

After a successful qemu-img/qcow-create of the backing file, if we fail to stat the file, change it owner/group, or mode, then the cleanup path should delete the file. Also moved the virCommandSetUID/virCommandSetGID inside the condition used to actually run the command rather than randomly

[libvirt] [PATCH 02/12] storage: Remove duplicitous refreshVol in Sheepdog buildVol

As of commit id '155ca616' a 'refreshVol' is called after a buildVol succeeds in storageVolCreateXML, thus a volStorageBackendSheepdogRefreshVolInfo call in virStorageBackendSheepdogBuildVol is no longer necessary. Additionally, the 'conn' parameter becomes unused. Signed-off-by: John Ferlan

[libvirt] [PATCH 00/12] Have 'buildVol' callers to clean up after themselves

NOTE: Although one may consider this a v2 of : http://www.redhat.com/archives/libvir-list/2015-October/msg00196.html It's more tackling the same problem a different way... Rather than pass a 'created' boolean around, this series investigated each of the 'createVol' and 'buildVol' paths in order

Re: [libvirt] [PATCH] src: Include $(builddir)/util in the header search path

On Fri, 2015-10-09 at 09:55 +0200, Martin Kletzander wrote: > With this we could stop generating whole bunch of other stuff in > $(srcdir) See output of `git grep -F '> $(srcdir)'` for details =) That would be very nice indeed! I'll look into it. Cheers. -- Andrea Bolognani Software Engineer

[libvirt] [PATCH 07/12] storage: Rework error paths for virStorageBackendCreateExecCommand

Rework the code in order to use the "ret = -1;" and goto cleanup; coding style. Signed-off-by: John Ferlan --- src/storage/storage_backend.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/src/storage/storage_backend.c

[libvirt] [PATCH 06/12] storage: On error rmdir created directory in virDirCreate[NoFork]

After a successful creation of a directory, if some other call results in returning a failure, let's remove the directory we created to prevent another round trip or confusion in the caller. In particular, this function can be called during a storage backend buildVol, so in order to ensure that

[libvirt] [PATCH 03/12] storage: Fix a resource leak in storageVolCreateXML

Commit id '1b5685da' refactored the code to move buildvoldef inside the buildVol conditional; however, the VIR_FREE of the memory was left only when 'buildret' failed, thus we're leaking memory. Signed-off-by: John Ferlan --- src/storage/storage_driver.c | 3 ++- 1 file

[libvirt] [PATCH 11/12] Revert "storage: Prior to creating a volume, refresh the pool"

This reverts commit fdda37608a6e22406fbdfe4ac0c573a96a8d0417. This commit only manages a symptom of finding a buildRet failure where a volume was not listed in the pool, but someone created the volume outside of libvirt in the pool being managed by libvirt. Signed-off-by: John Ferlan

[libvirt] [PATCH 01/12] storage: Remove duplicitous refreshVol in RBD buildVol

As of commit id '155ca616' a 'refreshVol' is called after the buildVol succeeds in storageVolCreateXML, thus the volStorageBackendRBDRefreshVolInfo call in virStorageBackendRBDBuildVol is no longer necessary. Signed-off-by: John Ferlan --- src/storage/storage_backend_rbd.c |

[libvirt] [PATCH 09/12] storage: Cleanup failures in virStorageBackendCreateRaw

If the volume target path doesn't exist prior to calling virFileOpenAs and we have a successful call, then we know we've had a successful creation. For any other failures in the function we should clean up after ourselves by using virFileDelete if we're about to return failure. Signed-off-by:

[libvirt] [PATCH 12/12] storage: On 'buildVol' failure don't delete the volume

https://bugzilla.redhat.com/show_bug.cgi?id=1233003 Commit id 'fdda3760' only managed a symptom where it was possible to create a file in a pool without libvirt's knowledge, so it was reverted. The real fix is to have all the createVol API's which actually create a volume (disk, logical, zfs)

[libvirt] [PATCH 10/12] storage: Pull volume removal from pool in storageVolDeleteInternal

Move the code that removes the volume from the pool into it's own API Signed-off-by: John Ferlan --- src/storage/storage_driver.c | 31 --- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/src/storage/storage_driver.c